Jeff King [off-list ref] writes:
Subject: t1304: improve setfacl prerequisite setup
+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
+'
Excellent. Thanks.
Tested-by: Matthieu Moy <redacted>
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Hi,
so I applied that patch with git apply, but here 2 out of 4 tests now
still fail.
sb@sb:~/OSS/git/t$ cat t1304-default-acl.sh
#!/bin/sh
#
# Copyright (c) 2010 Matthieu Moy
#
test_description='Test repository with default ACL'
# Create the test repo with restrictive umask
# => this must come before . ./test-lib.sh
umask 077
. ./test-lib.sh
# 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.
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
LOGNAME=$USER
fi
check_perms_and_acl () {
test -r "$1" &&
getfacl "$1" > actual &&
grep -q "user:root:rwx" actual &&
grep -q "user:${LOGNAME}:rwx" actual &&
egrep "mask::?r--" actual > /dev/null 2>&1 &&
grep -q "group::---" actual || false
}
dirs_to_set="./ .git/ .git/objects/ .git/objects/pack/"
test_expect_success SETFACL 'Setup test repo' '
setfacl -m d:u::rwx,d:g::---,d:o:---,d:m:rwx $dirs_to_set &&
setfacl -m m:rwx $dirs_to_set &&
setfacl -m u:root:rwx $dirs_to_set &&
setfacl -m d:u:"$LOGNAME":rwx $dirs_to_set &&
setfacl -m d:u:root:rwx $dirs_to_set &&
touch file.txt &&
git add file.txt &&
git commit -m "init"
'
test_expect_success SETFACL 'Objects creation does not break ACLs with
restrictive umask' '
# SHA1 for empty blob
check_perms_and_acl .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
'
test_expect_success SETFACL 'git gc does not break ACLs with
restrictive umask' '
git gc &&
check_perms_and_acl .git/objects/pack/*.pack
'
test_done
sb@sb:~/OSS/git/t$ ./t1304-default-acl.sh --verbose
Initialized empty Git repository in /home/sb/OSS/git/t/trash
directory.t1304-default-acl/.git/
expecting success:
if setfacl -m u:root:rwx . &&
getfacl . | grep user:root:rwx
then
test_set_prereq SETFACL
fi
user:root:rwx
ok 1 - checking for a working acl setup
expecting success:
setfacl -m d:u::rwx,d:g::---,d:o:---,d:m:rwx $dirs_to_set &&
setfacl -m m:rwx $dirs_to_set &&
setfacl -m u:root:rwx $dirs_to_set &&
setfacl -m d:u:"$LOGNAME":rwx $dirs_to_set &&
setfacl -m d:u:root:rwx $dirs_to_set &&
touch file.txt &&
git add file.txt &&
git commit -m "init"
[master (root-commit) 011f91a] init
Author: A U Thor [off-list ref]
0 files changed
create mode 100644 file.txt
ok 2 - Setup test repo
expecting success:
# SHA1 for empty blob
check_perms_and_acl .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
not ok - 3 Objects creation does not break ACLs with restrictive umask
#
# # SHA1 for empty blob
# check_perms_and_acl .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
#
expecting success:
git gc &&
check_perms_and_acl .git/objects/pack/*.pack
Counting objects: 3, done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 0 (delta 0)
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
2012/6/5 Matthieu Moy [off-list ref]:Jeff King [off-list ref] writes:
quoted
Subject: t1304: improve setfacl prerequisite setup
quoted
+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
+'
Excellent. Thanks.
Tested-by: Matthieu Moy <redacted>
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Tue, Jun 05, 2012 at 02:23:32PM +0200, Stefan Beller wrote:
so I applied that patch with git apply, but here 2 out of 4 tests now
still fail.
Hmm. So it seems that the test setfacl does actually work, but for some
reason what git does is making ecryptfs unhappy (but not any other
filesystem).
I just made a test ecryptfs filesystem, and I can easily replicate your
problem. I'll see if I can find out what git is doing to create this
weird state.
-Peff