summaryrefslogtreecommitdiff
path: root/t/t1304-default-acl.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-10-19t1304: Set LOGNAME even if USER is unset or nullLibravatar W. Trevor King1-1/+1
Avoid: # ./t1304-default-acl.sh ok 1 - checking for a working acl setup ok 2 - Setup test repo not ok 3 - Objects creation does not break ACLs with restrictive umask # # # SHA1 for empty blob # check_perms_and_acl .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 # not ok 4 - git gc does not break ACLs with restrictive umask # # git gc && # check_perms_and_acl .git/objects/pack/*.pack # # failed 2 among 4 test(s) 1..4 on systems where USER isn't set. It's usually set by the login process, but it isn't set when launching some Docker images. For example: $ docker run --rm debian env HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=b2dfdfe797ed 'id -u -n' has been in POSIX from Issue 2 through 2013 [1], so I don't expect compatibility issues. [1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/id.html Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-07t1304: improve setfacl prerequisite setupLibravatar Jeff King1-10/+9
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14t1304: fall back to $USER if $LOGNAME is not definedLibravatar René Scharfe1-0/+5
For some reason $LOGNAME is not set anymore for me after an upgrade from Ubuntu 11.04 to 11.10. Use $USER in such a case. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t/t1304-default-acl: change from skip_all=* to prereq skipLibravatar Ævar Arnfjörð Bjarmason1-6/+8
Change this test to skip test with test prerequisites, and to do setup work in tests. This improves the skipped statistics on platforms where the test isn't run. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25tests: Skip tests in a way that makes sense under TAPLibravatar Ævar Arnfjörð Bjarmason1-3/+6
SKIP messages are now part of the TAP plan. A TAP harness now knows why a particular test was skipped and can report that information. The non-TAP harness built into Git's test-lib did nothing special with these messages, and is unaffected by these changes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-16t/t1304: make a second colon optional in the mask ACL checkLibravatar Brandon Casey1-1/+1
Solaris only uses one colon in the listing of the ACL mask, Linux uses two, so substitute egrep for grep and make the second colon optional. The -q option for Solaris 7's /usr/xpg4/bin/egrep does not appear to be implemented, so redirect output to /dev/null. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-16t/t1304: set the ACL effective rights maskLibravatar Brandon Casey1-0/+1
Some implementations of setfacl do not recalculate the effective rights mask when the ACL is modified. So, set the effective rights mask explicitly to ensure that the ACL's that are set on the directories will have effect. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-16t/t1304: use 'test -r' to test readability rather than looking at mode bitsLibravatar Brandon Casey1-14/+1
This test was using the group read permission bit as an indicator of the default ACL mask. This behavior is valid on Linux but not on other platforms like Solaris. So, rather than looking at mode bits, just test readability for the user. This, along with the checks for the existence of the ACL's that were set on the parent directories, should be enough. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-16t/t1304: set the Default ACL base entriesLibravatar Brandon Casey1-0/+1
According to the Linux setfacl man page, in order for an ACL to be valid, the following rules must be satisfied: * Whenever an ACL contains any Default ACL entries, the three Default ACL base entries (default owner, default group, and default others) must also exist. * Whenever a Default ACL contains named user entries or named group objects, it must also contain a default effective rights mask. Some implementations of setfacl (Linux) do this automatically when necessary, some (Solaris) do not. Solaris's setfacl croaks when trying to create a default user ACL if the above rules are not satisfied. So, create them before modifying the default user ACL's. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-16t/t1304: avoid -d option to setfaclLibravatar Brandon Casey1-2/+2
Some platforms (Solaris) have a setfacl whose -d switch works differently than the one on Linux. On Linux, it causes all operations to be applied to the Default ACL. There is a notation for operating on the Default ACL: [d[efault]:] [u[ser]:]uid [:perms] so use it instead of the -d switch. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Use git_mkstemp_mode instead of plain mkstemp to create object filesLibravatar Matthieu Moy1-1/+1
We used to unnecessarily give the read permission to group and others, regardless of the umask, which isn't serious because the objects are still protected by their containing directory, but isn't necessary either. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later.Libravatar Matthieu Moy1-1/+1
We used to create 0600 files, and then use chmod to set the group and other permission bits to the umask. This usually has the same effect as a normal file creation with a umask. But in the presence of ACLs, the group permission plays the role of the ACL mask: the "g" bits of newly created files are chosen according to default ACL mask of the directory, not according to the umask, and doing a chmod() on these "g" bits affect the ACL's mask instead of actual group permission. In other words, creating files with 0600 and then doing a chmod to the umask creates files which are unreadable by users allowed in the default ACL. To create the files without breaking ACLs, we let the umask do it's job at the file's creation time, and get rid of the later chmod. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Add a testcase for ACL with restrictive umask.Libravatar Matthieu Moy1-0/+67
Right now, Git creates unreadable pack files on non-shared repositories when the user has a umask of 077, even when the default ACLs for the directory would give read/write access to a specific user. Loose object files are created world-readable, which doesn't break ACLs, but isn't necessarily desirable. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>