[apparmor] [patch] tests: readdir - test both getdents() and getdents64() if available

[Steve Beattie]

Hey Tyler,

On Tue, Apr 04, 2017 at 02:03:53PM -0500, Tyler Hicks wrote:
> On 04/04/2017 01:14 PM, Steve Beattie wrote:
> > -int main(int argc, char *argv[])
> > +#ifdef SYS_getdents
> > +int my_readdir(char *dirname)
> 
> Nitpick...
> 
> Please use my_getdents() and my_getdents64() since these are getdents
> wrappers and not readdir wrappers.

The reason for calling the function my_readdir() and not my_getdents()
is the same reason the whole test is called the same; they're emulating
the work that the libc readdir() function does. while ensuring that
glibc doesn't do anything underneath us that might invalidate our
assumptions about the test. But I'm not too chuffed one or the other
about the name.

> > +	rc = my_readdir(argv[1]);
> > +	if (rc != 0)
> > +		goto err;
> > +
> > +	rc = my_readdir64(argv[1]);
> > +	if (rc != 0)
> > +		goto err;
> 
> Objection...
> 
> In an expected fail test case, getdents64() will not be tested because
> getdents() will have already failed.
> 
> The test script should pass the expected behavior to the test program
> and the test program will need to verify that both syscalls match the
> expected behavior.
> 
> Alternatively, a shortcut would be to test both syscalls and if the
> results are different, raise an ERROR instead of a FAIL.

Yes, I thought about this a bit before submitting. The tricky situation
is cases like aarch64 (aka arm64) where the getdents() syscall doesn't
exist at all and the stub function is used instead. The test would
need to take this into account, perhaps by having the stub function
return -ENOSYS or something, to make the situation detectable.

I'll think about this more.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170404/d167cd8c/attachment.pgp>