development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-11-05 18:59:29 +00:00
Code Issues Projects Releases Packages Wiki Activity
git/t/t4115-apply-symlink.sh

145 lines
3.3 KiB
Bash
Raw Normal View History

git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
#!/bin/sh
#
# Copyright (c) 2005 Junio C Hamano
#
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 05:52:14 +00:00
test_description='git apply symlinks and partial files
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
'
checkout: fix "branch info" memory leaks The "checkout" command is one of the main sources of leaks in the test suite, let's fix the common ones by not leaking from the "struct branch_info". Doing this is rather straightforward, albeit verbose, we need to xstrdup() constant strings going into the struct, and free() the ones we clobber as we go along. This also means that we can delete previous partial leak fixes in this area, i.e. the "path_to_free" accounting added by 96ec7b1e708 (Convert resolve_ref+xstrdup to new resolve_refdup function, 2011-12-13). There was some discussion about whether "we should retain the "const char *" here and cast at free() time, or have it be a "char *". Since this is not a public API with any sort of API boundary let's use "char *", as is already being done for the "refname" member of the same struct. The tests to mark as passing were found with: rm .prove; GIT_SKIP_TESTS=t0027 prove -j8 --state=save t[0-9]*.sh :: --immediate # apply & compile this change prove -j8 --state=failed :: --immediate I.e. the ones that were newly passing when the --state=failed command was run. I left out "t3040-subprojects-basic.sh" and "t4131-apply-fake-ancestor.sh" to to optimization-level related differences similar to the ones noted in[1], except that these would be something the current 'linux-leaks' job would run into. 1. https://lore.kernel.org/git/cover-v3-0.6-00000000000-20211022T175227Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-16 18:27:38 +00:00
TEST_PASSES_SANITIZE_LEAK=true
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
. ./test-lib.sh
tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases) There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where "trivial" means: - merely a replacement of 'ln -s a b && git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 20:53:28 +00:00
test_expect_success setup '
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases) There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where "trivial" means: - merely a replacement of 'ln -s a b && git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 20:53:28 +00:00
test_ln_s_add path1/path2/path3/path4/path5 link1 &&
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
git commit -m initial &&
git branch side &&
rm -f link? &&
tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases) There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where "trivial" means: - merely a replacement of 'ln -s a b && git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 20:53:28 +00:00
test_ln_s_add htap6 link1 &&
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
git commit -m second &&
git diff-tree -p HEAD^ HEAD >patch &&
git apply --stat --summary patch
'
tests: implicitly skip SYMLINKS tests using <prereq> Change the tests that skipped due to unavailable SYMLINKS support to use the three-arg prereq form of test_expect_success. Now we get an indication of how many tests that need symlinks are being skipped on platforms that don't support them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-28 10:34:55 +00:00
test_expect_success SYMLINKS 'apply symlink patch' '
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
git checkout side &&
git apply patch &&
git diff-files -p >patched &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp patch patched
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
'
tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases) There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where "trivial" means: - merely a replacement of 'ln -s a b && git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 20:53:28 +00:00
test_expect_success 'apply --index symlink patch' '
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
git checkout -f side &&
git apply --index patch &&
git diff-index --cached -p HEAD >patched &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp patch patched
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
'
apply: fix writing behind newly created symbolic links When writing files git-apply(1) initially makes sure that none of the files it is about to create are behind a symlink: ``` $ git init repo Initialized empty Git repository in /tmp/repo/.git/ $ cd repo/ $ ln -s dir symlink $ git apply - <<EOF diff --git a/symlink/file b/symlink/file new file mode 100644 index 0000000..e69de29 EOF error: affected file 'symlink/file' is beyond a symbolic link ``` This safety mechanism is crucial to ensure that we don't write outside of the repository's working directory. It can be fooled though when the patch that is being applied creates the symbolic link in the first place, which can lead to writing files in arbitrary locations. Fix this by checking whether the path we're about to create is beyond a symlink or not. Tightening these checks like this should be fine as we already have these precautions in Git as explained above. Ideally, we should update the check we do up-front before starting to reflect the computed changes to the working tree so that we catch this case as well, but as part of embargoed security work, adding an equivalent check just before we try to write out a file should serve us well as a reasonable first step. Digging back into history shows that this vulnerability has existed since at least Git v2.9.0. As Git v2.8.0 and older don't build on my system anymore I cannot tell whether older versions are affected, as well. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-02 10:54:34 +00:00
test_expect_success 'symlink setup' '
ln -s .git symlink &&
git add symlink &&
git commit -m "add symlink"
'
test_expect_success SYMLINKS 'symlink escape when creating new files' '
test_when_finished "git reset --hard && git clean -dfx" &&
cat >patch <<-EOF &&
diff --git a/symlink b/renamed-symlink
similarity index 100%
rename from symlink
rename to renamed-symlink
--
diff --git /dev/null b/renamed-symlink/create-me
new file mode 100644
index 0000000..039727e
--- /dev/null
+++ b/renamed-symlink/create-me
@@ -0,0 +1,1 @@
+busted
EOF
test_must_fail git apply patch 2>stderr &&
cat >expected_stderr <<-EOF &&
error: affected file ${SQ}renamed-symlink/create-me${SQ} is beyond a symbolic link
EOF
test_cmp expected_stderr stderr &&
tests: do not negate test_path_exists As a way to assert the path 'foo' is missing, "! test_path_exists foo" is a poor way to do so, as the helper is designed to complain when 'foo' is missing, but the intention of the author who used negated form was to make sure it does not exist. This does not help debugging the tests. Use test_path_is_missing instead, which is a more appropriate helper. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-16 02:26:44 +00:00
test_path_is_missing .git/create-me
apply: fix writing behind newly created symbolic links When writing files git-apply(1) initially makes sure that none of the files it is about to create are behind a symlink: ``` $ git init repo Initialized empty Git repository in /tmp/repo/.git/ $ cd repo/ $ ln -s dir symlink $ git apply - <<EOF diff --git a/symlink/file b/symlink/file new file mode 100644 index 0000000..e69de29 EOF error: affected file 'symlink/file' is beyond a symbolic link ``` This safety mechanism is crucial to ensure that we don't write outside of the repository's working directory. It can be fooled though when the patch that is being applied creates the symbolic link in the first place, which can lead to writing files in arbitrary locations. Fix this by checking whether the path we're about to create is beyond a symlink or not. Tightening these checks like this should be fine as we already have these precautions in Git as explained above. Ideally, we should update the check we do up-front before starting to reflect the computed changes to the working tree so that we catch this case as well, but as part of embargoed security work, adding an equivalent check just before we try to write out a file should serve us well as a reasonable first step. Digging back into history shows that this vulnerability has existed since at least Git v2.9.0. As Git v2.8.0 and older don't build on my system anymore I cannot tell whether older versions are affected, as well. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-02 10:54:34 +00:00
'
test_expect_success SYMLINKS 'symlink escape when modifying file' '
test_when_finished "git reset --hard && git clean -dfx" &&
touch .git/modify-me &&
cat >patch <<-EOF &&
diff --git a/symlink b/renamed-symlink
similarity index 100%
rename from symlink
rename to renamed-symlink
--
diff --git a/renamed-symlink/modify-me b/renamed-symlink/modify-me
index 1111111..2222222 100644
--- a/renamed-symlink/modify-me
+++ b/renamed-symlink/modify-me
@@ -0,0 +1,1 @@
+busted
EOF
test_must_fail git apply patch 2>stderr &&
cat >expected_stderr <<-EOF &&
error: renamed-symlink/modify-me: No such file or directory
EOF
test_cmp expected_stderr stderr &&
test_must_be_empty .git/modify-me
'
test_expect_success SYMLINKS 'symlink escape when deleting file' '
test_when_finished "git reset --hard && git clean -dfx && rm .git/delete-me" &&
touch .git/delete-me &&
cat >patch <<-EOF &&
diff --git a/symlink b/renamed-symlink
similarity index 100%
rename from symlink
rename to renamed-symlink
--
diff --git a/renamed-symlink/delete-me b/renamed-symlink/delete-me
deleted file mode 100644
index 1111111..0000000 100644
EOF
test_must_fail git apply patch 2>stderr &&
cat >expected_stderr <<-EOF &&
error: renamed-symlink/delete-me: No such file or directory
EOF
test_cmp expected_stderr stderr &&
test_path_is_file .git/delete-me
'
apply --reject: overwrite existing `.rej` symlink if it exists The `git apply --reject` is expected to write out `.rej` files in case one or more hunks fail to apply cleanly. Historically, the command overwrites any existing `.rej` files. The idea being that apply/reject/edit cycles are relatively common, and the generated `.rej` files are not considered precious. But the command does not overwrite existing `.rej` symbolic links, and instead follows them. This is unsafe because the same patch could potentially create such a symbolic link and point at arbitrary paths outside the current worktree, and `git apply` would write the contents of the `.rej` file into that location. Therefore, let's make sure that any existing `.rej` file or symbolic link is removed before writing it. Reported-by: RyotaK <ryotak.mail@gmail.com> Helped-by: Taylor Blau <me@ttaylorr.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Linus Torvalds <torvalds@linuxfoundation.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2023-03-09 15:02:54 +00:00
test_expect_success SYMLINKS '--reject removes .rej symlink if it exists' '
test_when_finished "git reset --hard && git clean -dfx" &&
test_commit file &&
echo modified >file.t &&
git diff -- file.t >patch &&
echo modified-again >file.t &&
ln -s foo file.t.rej &&
test_must_fail git apply patch --reject 2>err &&
test_i18ngrep "Rejected hunk" err &&
test_path_is_missing foo &&
test_path_is_file file.t.rej
'
git-apply: applying a patch to make a symlink shorter. The internal representation of the result is counted string (i.e. char *buf and ulong size), which is fine for writing out to regular file, but throwing the buf at symlink(2) was a no-no. Reported by Willy Tarreau. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10 05:47:25 +00:00
test_done
Reference in a new issue Copy permalink