kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
W. Trevor King	7544b2e2da	t1304: Set LOGNAME even if USER is unset or null 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>	11 years ago
Jeff King	a14ad10911	t1304: improve setfacl prerequisite setup 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>	13 years ago
René Scharfe	ac2604cf5f	t1304: fall back to $USER if $LOGNAME is not defined 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>	14 years ago
Ævar Arnfjörð Bjarmason	063b7e0cd4	t/t1304-default-acl: change from skip_all=* to prereq skip 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>	15 years ago
Ævar Arnfjörð Bjarmason	fadb5156e4	tests: Skip tests in a way that makes sense under TAP 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>	15 years ago
Brandon Casey	80700fde91	t/t1304: make a second colon optional in the mask ACL check 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>	15 years ago
Brandon Casey	2e85575a02	t/t1304: set the ACL effective rights mask 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>	15 years ago
Brandon Casey	71c4d6c635	t/t1304: use 'test -r' to test readability rather than looking at mode bits 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>	15 years ago
Brandon Casey	ab04a90567	t/t1304: set the Default ACL base entries 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>	15 years ago
Brandon Casey	db826571e4	t/t1304: avoid -d option to setfacl 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>	15 years ago
Matthieu Moy	5256b00631	Use git_mkstemp_mode instead of plain mkstemp to create object files 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>	15 years ago
Matthieu Moy	f80c7ae8fe	Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later. 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>	15 years ago
Matthieu Moy	7aba6185d5	Add a testcase for ACL with restrictive umask. 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>	15 years ago

13 Commits (5a74ce22e61ce0c8d7325b891ef1a926cf4f6154)