git-commit-vandalism/t/t1301-shared-repo.sh

213 lines
4.9 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2007 Johannes Schindelin
#
test_description='Test shared repository initialization'
. ./test-lib.sh
# Remove a default ACL from the test dir if possible.
setfacl -k . 2>/dev/null
# User must have read permissions to the repo -> failure on --shared=0400
test_expect_success 'shared = 0400 (faulty permission u-w)' '
test_when_finished "rm -rf sub" &&
mkdir sub && (
cd sub &&
test_must_fail git init --shared=0400
)
'
for u in 002 022
do
test_expect_success POSIXPERM "shared=1 does not clear bits preset by umask $u" '
mkdir sub && (
cd sub &&
umask $u &&
git init --shared=1 &&
test 1 = "$(git config core.sharedrepository)"
) &&
actual=$(ls -l sub/.git/HEAD) &&
case "$actual" in
-rw-rw-r--*)
: happy
;;
*)
echo Oops, .git/HEAD is not 0664 but $actual
false
;;
esac
'
rm -rf sub
done
test_expect_success 'shared=all' '
mkdir sub &&
cd sub &&
git init --shared=all &&
test 2 = $(git config core.sharedrepository)
'
test_expect_success POSIXPERM 'update-server-info honors core.sharedRepository' '
: > a1 &&
git add a1 &&
test_tick &&
git commit -m a1 &&
umask 0277 &&
git update-server-info &&
actual="$(ls -l .git/info/refs)" &&
case "$actual" in
-r--r--r--*)
: happy
;;
*)
echo Oops, .git/info/refs is not 0444
false
;;
esac
'
for u in 0660:rw-rw---- \
0640:rw-r----- \
0600:rw------- \
0666:rw-rw-rw- \
0664:rw-rw-r--
do
x=$(expr "$u" : ".*:\([rw-]*\)") &&
y=$(echo "$x" | sed -e "s/w/-/g") &&
u=$(expr "$u" : "\([0-7]*\)") &&
git config core.sharedrepository "$u" &&
umask 0277 &&
test_expect_success POSIXPERM "shared = $u ($y) ro" '
rm -f .git/info/refs &&
git update-server-info &&
actual="$(test_modebits .git/info/refs)" &&
verbose test "x$actual" = "x-$y"
'
umask 077 &&
test_expect_success POSIXPERM "shared = $u ($x) rw" '
rm -f .git/info/refs &&
git update-server-info &&
actual="$(test_modebits .git/info/refs)" &&
verbose test "x$actual" = "x-$x"
'
done
test_expect_success POSIXPERM 'info/refs respects umask in unshared repo' '
rm -f .git/info/refs &&
test_unconfig core.sharedrepository &&
umask 002 &&
git update-server-info &&
echo "-rw-rw-r--" >expect &&
test_modebits .git/info/refs >actual &&
test_cmp expect actual
'
test_expect_success POSIXPERM 'git reflog expire honors core.sharedRepository' '
umask 077 &&
git config core.sharedRepository group &&
git reflog expire --all &&
actual="$(ls -l .git/logs/refs/heads/master)" &&
case "$actual" in
-rw-rw-*)
: happy
;;
*)
echo Ooops, .git/logs/refs/heads/master is not 0662 [$actual]
false
;;
esac
'
test_expect_success POSIXPERM 'forced modes' '
mkdir -p templates/hooks &&
echo update-server-info >templates/hooks/post-update &&
chmod +x templates/hooks/post-update &&
echo : >random-file &&
mkdir new &&
(
cd new &&
umask 002 &&
git init --shared=0660 --template=../templates &&
>frotz &&
git add frotz &&
git commit -a -m initial &&
git repack
) &&
t1301-shared-repo: fix forced modes test This test was added recently (5a688fe, "core.sharedrepository = 0mode" should set, not loosen; 2009-03-28). It checked the result of a sed invocation for emptyness, but in some cases it forgot to print anything at all, so that those checks would never be false. Due to this mistake, it went unnoticed that the files in objects/info are not necessarily 0440, but can also be 0660. Because the 0mode setting tries to guarantee that the files are accessible only to the people they are meant to be used by, we should only make sure that they are readable by the user and the group when the configuration is set to 0660. It is a separate matter from the core.shredrepository settings that w-bit from immutable object files under objects/[0-9a-f][0-9a-f] directories should be dropped. COMMIT_EDITMSG is still world-readable, but it (and any transient files that are meant for repositories with a work tree) does not matter. If you are working on a shared machine and on a sekrit stuff, the root of the work tree would be with mode 0700 (or 0750 to allow peeking by other people in the group), and that would mean that .git/COMMIT_EDITMSG in such a repository would not be readable by the strangers anyway. Also, in the real-world use case, .git/COMMIT_EDITMSG will be given to an arbitrary editor the user happens to use, and we have no guarantee what it does (e.g. it may create a new file with umask and replace, it may rewrite in place, it may leave an editor backup file but use umask to create it, etc.), and the protection of the file lies majorly on the protection of the root of the work tree. This test cannot be run on Windows; it requires POSIXPERM when merged to 'master'. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 21:22:02 +02:00
# List repository files meant to be protected; note that
# COMMIT_EDITMSG does not matter---0mode is not about a
# repository with a work tree.
find new/.git -type f -name COMMIT_EDITMSG -prune -o -print |
xargs ls -ld >actual &&
# Everything must be unaccessible to others
t1301-shared-repo: fix forced modes test This test was added recently (5a688fe, "core.sharedrepository = 0mode" should set, not loosen; 2009-03-28). It checked the result of a sed invocation for emptyness, but in some cases it forgot to print anything at all, so that those checks would never be false. Due to this mistake, it went unnoticed that the files in objects/info are not necessarily 0440, but can also be 0660. Because the 0mode setting tries to guarantee that the files are accessible only to the people they are meant to be used by, we should only make sure that they are readable by the user and the group when the configuration is set to 0660. It is a separate matter from the core.shredrepository settings that w-bit from immutable object files under objects/[0-9a-f][0-9a-f] directories should be dropped. COMMIT_EDITMSG is still world-readable, but it (and any transient files that are meant for repositories with a work tree) does not matter. If you are working on a shared machine and on a sekrit stuff, the root of the work tree would be with mode 0700 (or 0750 to allow peeking by other people in the group), and that would mean that .git/COMMIT_EDITMSG in such a repository would not be readable by the strangers anyway. Also, in the real-world use case, .git/COMMIT_EDITMSG will be given to an arbitrary editor the user happens to use, and we have no guarantee what it does (e.g. it may create a new file with umask and replace, it may rewrite in place, it may leave an editor backup file but use umask to create it, etc.), and the protection of the file lies majorly on the protection of the root of the work tree. This test cannot be run on Windows; it requires POSIXPERM when merged to 'master'. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 21:22:02 +02:00
test -z "$(sed -e "/^.......---/d" actual)" &&
# All directories must have either 2770 or 770
test -z "$(sed -n -e "/^drwxrw[sx]---/d" -e "/^d/p" actual)" &&
# post-update hook must be 0770
test -z "$(sed -n -e "/post-update/{
/^-rwxrwx---/d
p
}" actual)" &&
t1301-shared-repo: fix forced modes test This test was added recently (5a688fe, "core.sharedrepository = 0mode" should set, not loosen; 2009-03-28). It checked the result of a sed invocation for emptyness, but in some cases it forgot to print anything at all, so that those checks would never be false. Due to this mistake, it went unnoticed that the files in objects/info are not necessarily 0440, but can also be 0660. Because the 0mode setting tries to guarantee that the files are accessible only to the people they are meant to be used by, we should only make sure that they are readable by the user and the group when the configuration is set to 0660. It is a separate matter from the core.shredrepository settings that w-bit from immutable object files under objects/[0-9a-f][0-9a-f] directories should be dropped. COMMIT_EDITMSG is still world-readable, but it (and any transient files that are meant for repositories with a work tree) does not matter. If you are working on a shared machine and on a sekrit stuff, the root of the work tree would be with mode 0700 (or 0750 to allow peeking by other people in the group), and that would mean that .git/COMMIT_EDITMSG in such a repository would not be readable by the strangers anyway. Also, in the real-world use case, .git/COMMIT_EDITMSG will be given to an arbitrary editor the user happens to use, and we have no guarantee what it does (e.g. it may create a new file with umask and replace, it may rewrite in place, it may leave an editor backup file but use umask to create it, etc.), and the protection of the file lies majorly on the protection of the root of the work tree. This test cannot be run on Windows; it requires POSIXPERM when merged to 'master'. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 21:22:02 +02:00
# All files inside objects must be accessible by us
test -z "$(sed -n -e "/objects\//{
/^d/d
t1301-shared-repo: fix forced modes test This test was added recently (5a688fe, "core.sharedrepository = 0mode" should set, not loosen; 2009-03-28). It checked the result of a sed invocation for emptyness, but in some cases it forgot to print anything at all, so that those checks would never be false. Due to this mistake, it went unnoticed that the files in objects/info are not necessarily 0440, but can also be 0660. Because the 0mode setting tries to guarantee that the files are accessible only to the people they are meant to be used by, we should only make sure that they are readable by the user and the group when the configuration is set to 0660. It is a separate matter from the core.shredrepository settings that w-bit from immutable object files under objects/[0-9a-f][0-9a-f] directories should be dropped. COMMIT_EDITMSG is still world-readable, but it (and any transient files that are meant for repositories with a work tree) does not matter. If you are working on a shared machine and on a sekrit stuff, the root of the work tree would be with mode 0700 (or 0750 to allow peeking by other people in the group), and that would mean that .git/COMMIT_EDITMSG in such a repository would not be readable by the strangers anyway. Also, in the real-world use case, .git/COMMIT_EDITMSG will be given to an arbitrary editor the user happens to use, and we have no guarantee what it does (e.g. it may create a new file with umask and replace, it may rewrite in place, it may leave an editor backup file but use umask to create it, etc.), and the protection of the file lies majorly on the protection of the root of the work tree. This test cannot be run on Windows; it requires POSIXPERM when merged to 'master'. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 21:22:02 +02:00
/^-r.-r.----/d
p
}" actual)"
'
config: only read .git/config from configured repos When git_config() runs, it looks in the system, user-wide, and repo-level config files. It gets the latter by calling git_pathdup(), which in turn calls get_git_dir(). If we haven't set up the git repository yet, this may simply return ".git", and we will look at ".git/config". This seems like it would be helpful (presumably we haven't set up the repository yet, so it tries to find it), but it turns out to be a bad idea for a few reasons: - it's not sufficient, and therefore hides bugs in a confusing way. Config will be respected if commands are run from the top-level of the working tree, but not from a subdirectory. - it's not always true that we haven't set up the repository _yet_; we may not want to do it at all. For instance, if you run "git init /some/path" from inside another repository, it should not load config from the existing repository. - there might be a path ".git/config", but it is not the actual repository we would find via setup_git_directory(). This may happen, e.g., if you are storing a git repository inside another git repository, but have munged one of the files in such a way that the inner repository is not valid (e.g., by removing HEAD). We have at least two bugs of the second type in git-init, introduced by ae5f677 (lazily load core.sharedrepository, 2016-03-11). It causes init to use git_configset(), which loads all of the config, including values from the current repo (if any). This shows up in two ways: 1. If we happen to be in an existing repository directory, we'll read and respect core.sharedrepository from it, even though it should have no bearing on the new repository. A new test in t1301 covers this. 2. Similarly, if we're in an existing repo that sets core.logallrefupdates, that will cause init to fail to set it in a newly created repository (because it thinks that the user's templates already did so). A new test in t0001 covers this. We also need to adjust an existing test in t1302, which gives another example of why this patch is an improvement. That test creates an embedded repository with a bogus core.repositoryformatversion of "99". It wants to make sure that we actually stop at the bogus repo rather than continuing upward to find the outer repo. So it checks that "git config core.repositoryformatversion" returns 99. But that only works because we blindly read ".git/config", even though we _know_ we're in a repository whose vintage we do not understand. After this patch, we avoid reading config from the unknown vintage repository at all, which is a safer choice. But we need to tweak the test, since core.repositoryformatversion will not return 99; it will claim that it could not find the variable at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13 05:24:15 +02:00
test_expect_success POSIXPERM 'remote init does not use config from cwd' '
git config core.sharedrepository 0666 &&
umask 0022 &&
git init --bare child.git &&
echo "-rw-r--r--" >expect &&
test_modebits child.git/config >actual &&
config: only read .git/config from configured repos When git_config() runs, it looks in the system, user-wide, and repo-level config files. It gets the latter by calling git_pathdup(), which in turn calls get_git_dir(). If we haven't set up the git repository yet, this may simply return ".git", and we will look at ".git/config". This seems like it would be helpful (presumably we haven't set up the repository yet, so it tries to find it), but it turns out to be a bad idea for a few reasons: - it's not sufficient, and therefore hides bugs in a confusing way. Config will be respected if commands are run from the top-level of the working tree, but not from a subdirectory. - it's not always true that we haven't set up the repository _yet_; we may not want to do it at all. For instance, if you run "git init /some/path" from inside another repository, it should not load config from the existing repository. - there might be a path ".git/config", but it is not the actual repository we would find via setup_git_directory(). This may happen, e.g., if you are storing a git repository inside another git repository, but have munged one of the files in such a way that the inner repository is not valid (e.g., by removing HEAD). We have at least two bugs of the second type in git-init, introduced by ae5f677 (lazily load core.sharedrepository, 2016-03-11). It causes init to use git_configset(), which loads all of the config, including values from the current repo (if any). This shows up in two ways: 1. If we happen to be in an existing repository directory, we'll read and respect core.sharedrepository from it, even though it should have no bearing on the new repository. A new test in t1301 covers this. 2. Similarly, if we're in an existing repo that sets core.logallrefupdates, that will cause init to fail to set it in a newly created repository (because it thinks that the user's templates already did so). A new test in t0001 covers this. We also need to adjust an existing test in t1302, which gives another example of why this patch is an improvement. That test creates an embedded repository with a bogus core.repositoryformatversion of "99". It wants to make sure that we actually stop at the bogus repo rather than continuing upward to find the outer repo. So it checks that "git config core.repositoryformatversion" returns 99. But that only works because we blindly read ".git/config", even though we _know_ we're in a repository whose vintage we do not understand. After this patch, we avoid reading config from the unknown vintage repository at all, which is a safer choice. But we need to tweak the test, since core.repositoryformatversion will not return 99; it will claim that it could not find the variable at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13 05:24:15 +02:00
test_cmp expect actual
'
test_expect_success POSIXPERM 're-init respects core.sharedrepository (local)' '
git config core.sharedrepository 0666 &&
umask 0022 &&
echo whatever >templates/foo &&
git init --template=templates &&
echo "-rw-rw-rw-" >expect &&
test_modebits .git/foo >actual &&
test_cmp expect actual
'
test_expect_success POSIXPERM 're-init respects core.sharedrepository (remote)' '
rm -rf child.git &&
umask 0022 &&
git init --bare --shared=0666 child.git &&
test_path_is_missing child.git/foo &&
git init --bare --template=../templates child.git &&
echo "-rw-rw-rw-" >expect &&
test_modebits child.git/foo >actual &&
test_cmp expect actual
'
test_expect_success POSIXPERM 'template can set core.sharedrepository' '
rm -rf child.git &&
umask 0022 &&
git config core.sharedrepository 0666 &&
cp .git/config templates/config &&
git init --bare --template=../templates child.git &&
echo "-rw-rw-rw-" >expect &&
test_modebits child.git/HEAD >actual &&
test_cmp expect actual
'
test_done