Re: [PATCH] t1304: improve setfacl prerequisite setup

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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@peff.net>
> ---
> 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