git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Bugreport on Ubuntu LTS: not ok - 2 Objects creation does not break ACLs with restrictive umask

From
Jeff King <peff@peff.net>
Date
Jun 5, 2012, 07:56 UTC
Message-ID
<20120605075614.GE25809@sigill.intra.peff.net>
In-Reply-To
<CALbm-EZrKGaj1Q7gbmPmG0wQHxksnJqaS3bz3tMDsego7Zm2ZQ@mail.gmail.com>
On Tue, Jun 05, 2012 at 09:23:47AM +0200, Stefan Beller wrote:
> So I am using /dev/sda4 on /home type ext4 (rw), but my user account
> has its home directory encrypted via ecryptfs.

It's very likely that ecryptfs is the problem, then. Googling around, I find conflicting reports on whether it actually supports ACLs or not.

At the top of the test script we check that "setfacl" doesn't report an error, and assume that ACLs work if it doesn't. Maybe that test needs to be more comprehensive, like the patch below. What happens when you run t1304 with this patch (my expectation is that it will just skip the acl tests)?

-- >8 --
Subject: t1304: improve setfacl prerequisite setup

Some filesystems will cause "setfacl" to report success, even though they do not seem to behave sanely enough for our tests. Let's make sure that not only does setfacl work, but that we can read back the result.

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>
---
 t/t1304-default-acl.sh | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/t/t1304-default-acl.sh b/t/t1304-default-acl.sh
index 2b962cf..be954f0 100755
--- a/t/t1304-default-acl.sh
+++ b/t/t1304-default-acl.sh
@@ -14,16 +14,13 @@ 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 u:root:rwx . &&
+	   getfacl . | grep user:root:rwx
+	then
+		test_set_prereq SETFACL
+	fi
+'
 
 if test -z "$LOGNAME"
 then
Previous: Stefan BellerNext: Matthieu Moy
Message 7 of 26 in “Bugreport on Ubuntu LTS: not ok - 2 Objects creation does not break ACLs with restrictive umask”
  1. Stefan BellerJun 4, 2012
  2. Junio C HamanoJun 4, 2012
  3. Junio C HamanoJun 4, 2012
  4. Matthieu MoyJun 5, 2012
  5. Stefan BellerJun 5, 2012
  6. Stefan BellerJun 5, 2012
  7. Jeff KingJun 5, 2012
  8. Matthieu MoyJun 5, 2012
  9. Stefan BellerJun 5, 2012
  10. Matthieu MoyJun 5, 2012
  11. Jeff KingJun 5, 2012
  12. Jeff KingJun 5, 2012
  13. Jeff KingJun 5, 2012
  14. Jeff KingJun 5, 2012
  15. Junio C HamanoJun 5, 2012
  16. Jeff KingJun 5, 2012
  17. Junio C HamanoJun 5, 2012
  18. t1304: improve setfacl prerequisite setupJeff King, Jun 6, 2012
  19. Stefan BellerJun 6, 2012
  20. Junio C HamanoJun 6, 2012
  21. Jeff KingJun 7, 2012
  22. Junio C HamanoJun 7, 2012
  23. Brandon CaseyJun 8, 2012
  24. Tyler HicksJun 5, 2012
  25. Stefan BellerJun 5, 2012
  26. Jeff KingJun 5, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.