Jeff King <peff@xxxxxxxx> writes: > t1304 first runs setfacl as an experiment to see whether the > filesystem supports ACLs, and skips the remaining tests if > it does not. However, our setfacl run did not exercise the > ACLs very well, and some filesystems may support our initial > setfacl, but not the rest of the test. > > In particular, some versions of ecryptfs will erroneously > apply the umask on top of an inherited directory ACL, > causing our tests to fail. Let's be more careful and make > sure both that we can read back the user ACL we set, and > that the inherited ACL is propagated correctly. The latter > catches the ecryptfs bug, but may also catch other bugs > (e.g., an implementation which does not handle inherited > ACLs at all). > > Since we're making the setup more complex, let's move it > into its own test. This will hide the output for us unless > the user wants to run "-v" to see it (and we don't need to > bother printing anything about setfacl failing; the > remaining tests will properly print "skip" due to the > missing prerequisite). > > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > The ecryptfs response was that it is probably a bug, so I think we > should go with this (especially because it is general enough to > potentially catch other weird errors). > > t/t1304-default-acl.sh | 19 +++++++++---------- > 1 file changed, 9 insertions(+), 10 deletions(-) > > diff --git a/t/t1304-default-acl.sh b/t/t1304-default-acl.sh > index 2b962cf..79045ab 100755 > --- a/t/t1304-default-acl.sh > +++ b/t/t1304-default-acl.sh > @@ -14,16 +14,15 @@ umask 077 > # We need an arbitrary other user give permission to using ACLs. root > # is a good candidate: exists on all unices, and it has permission > # anyway, so we don't create a security hole running the testsuite. > - > -setfacl_out="$(setfacl -m u:root:rwx . 2>&1)" > -setfacl_ret=$? > - > -if test $setfacl_ret != 0 > -then > - say "Unable to use setfacl (output: '$setfacl_out'; return code: '$setfacl_ret')" > -else > - test_set_prereq SETFACL > -fi > +test_expect_success 'checking for a working acl setup' ' > + if setfacl -m d:m:rwx -m u:root:rwx . && > + getfacl . | grep user:root:rwx && > + touch should-have-readable-acl && > + getfacl should-have-readable-acl | egrep "mask::?rw-" At this point of the test, I do not think there is anything that can cause this check to be fooled by a user whose name is 'mask', but please make it a habit to anchor the pattern at the left. The tests done in check_perms_and_acl do risk getting fooled by a user whose name is 'mask', and need to be updated, I think, but that is a separate issue. > + then > + test_set_prereq SETFACL > + fi > +' > > if test -z "$LOGNAME" > then -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html