All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 4/4] apply: do not touch a file beyond a symbolic link
Date: Tue, 03 Feb 2015 13:01:06 -0800	[thread overview]
Message-ID: <xmqqy4oepv59.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150203011139.GC31946@peff.net> (Jeff King's message of "Mon, 2 Feb 2015 20:11:40 -0500")

Jeff King <peff@peff.net> writes:

> Here's the test addition I came up with, because it didn't look like we
> were covering this case. 

Thanks.

> diff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh
> index 942c5cb..fbba8dd 100755
> --- a/t/t4122-apply-symlink-inside.sh
> +++ b/t/t4122-apply-symlink-inside.sh
> @@ -89,6 +89,7 @@ test_expect_success SYMLINKS 'do not follow symbolic link (setup)' '
>  	rm -fr arch/x86_64/dir &&
>  
>  	cat add_symlink.patch add_file.patch >patch &&
> +	cat add_symlink.patch del_file.patch >tricky_del &&

This new patch

 (1) creates a symlink arch/x86_64/dir pointing at ../i386/dir
 (2) deletes arch/x86_64/dir/file

It can be a valid patch to be applied to a tree where arch/x86_64/dir/file
is in the index (either as a regular file, a symlink, or even a submodule)
and nothing else is in arch/x86_64/dir directory.


> @@ -112,6 +113,20 @@ test_expect_success SYMLINKS 'do not follow symbolic link (same input)' '
>  	test_i18ngrep "beyond a symbolic link" error-ct &&
>  	test_must_fail git ls-files --error-unmatch arch/x86_64/dir &&
>  	test_must_fail git ls-files --error-unmatch arch/i386/dir
> +
> +	>arch/i386/dir/file &&
> +	git add arch/i386/dir/file &&

At this point, the target of the patch application has:

	arch/i386/boot/Makefile
	arch/i386/dir/file
	arch/x86_64/boot/Makefile

all of which are regular files.  The index and the working tree
match.

> +	test_must_fail git apply tricky_del &&

The reason why this does not apply has nothing to do with the topic
of this series, I think.  It wants to delete arch/x86_64/dir/file,
which does not exist in the target, and the patch is rejected.

It is a good test to make sure that we do not "incrementally" apply
and get fooled by arch/x86_64/dir that will become a symbolic link,
making arch/x86_64/dir/file to appear as arch/i386/dir/file that
does exist in the preimage.

> +	test_path_is_file arch/i386/dir/file &&

When we reject the entire patch, we do so without touching the
outside world, of course ;-), which is good.

> +	test_must_fail git apply --index tricky_del &&
> +	test_path_is_file arch/i386/dir/file &&
> +	test_must_fail git ls-files --error-unmatch arch/x86_64/dir &&
> +	git ls-files --error-unmatch arch/i386/dir &&
> +
> +	test_must_fail git apply --cached tricky_del &&
> +	test_must_fail git ls-files --error-unmatch arch/x86_64/dir &&
> +	git ls-files --error-unmatch arch/i386/dir
>  '

In both of the above, "git apply" rejects its input for the same
reason.  The file it wants to remove does not exist in the target.

>  test_expect_success SYMLINKS 'do not follow symbolic link (existing)' '
> @@ -125,6 +140,7 @@ test_expect_success SYMLINKS 'do not follow symbolic link (existing)' '
>  	test_i18ngrep "beyond a symbolic link" error-wt-add &&
>  	test_path_is_missing arch/i386/dir/file &&
>  
> +	mkdir arch/i386/dir &&

Thanks for spotting this one ;-)

>  	>arch/i386/dir/file &&
>  	test_must_fail git apply del_file.patch 2>error-wt-del &&

del_file.patch wants to remove arch/x86_64/dir/file, and arch/x86_64/dir
is a symbolic link to ../i386/dir in the target at this point, so it
is trying to delete beyond the symbolic link, which gets rejected by
this series.  Good.

>  	test_i18ngrep "beyond a symbolic link" error-wt-del &&

  parent reply	other threads:[~2015-02-03 21:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-02 23:27 [PATCH v2 0/4] "git apply" safety Junio C Hamano
2015-02-02 23:27 ` [PATCH v2 1/4] apply: reject input that touches outside $cwd Junio C Hamano
2015-02-03  0:45   ` Jeff King
2015-02-03  0:50   ` Jeff King
2015-02-03 20:23     ` Junio C Hamano
2015-02-03 21:01       ` Jeff King
2015-02-03 21:23         ` Junio C Hamano
2015-02-03 21:24           ` Jeff King
2015-02-03 21:40             ` Junio C Hamano
2015-02-03 21:50               ` Jeff King
2015-02-03 22:11                 ` Junio C Hamano
2015-02-03  5:56   ` Torsten Bögershausen
2015-02-02 23:27 ` [PATCH v2 2/4] apply: do not read from the filesystem under --index Junio C Hamano
2015-02-02 23:27 ` [PATCH v2 3/4] apply: do not read from beyond a symbolic link Junio C Hamano
2015-02-03  0:08   ` Stefan Beller
2015-02-03 19:37     ` Junio C Hamano
2015-02-03 19:44       ` Stefan Beller
2015-02-03 20:31         ` Junio C Hamano
2015-02-02 23:27 ` [PATCH v2 4/4] apply: do not touch a file " Junio C Hamano
2015-02-03  1:11   ` Jeff King
2015-02-03  1:56     ` Junio C Hamano
2015-02-03  2:04       ` Jeff King
2015-02-03 21:01     ` Junio C Hamano [this message]
2015-02-03 23:40       ` Eric Sunshine
2015-02-04  0:44 ` [PATCH v3 0/4] "git apply" safety Junio C Hamano
2015-02-04  0:44   ` [PATCH v3 1/4] apply: reject input that touches outside the working area Junio C Hamano
2015-02-04  0:44   ` [PATCH v3 2/4] apply: do not read from the filesystem under --index Junio C Hamano
2015-02-04  0:44   ` [PATCH v3 3/4] apply: do not read from beyond a symbolic link Junio C Hamano
2015-02-04  0:44   ` [PATCH v3 4/4] apply: do not touch a file " Junio C Hamano
2015-02-10 22:36   ` [PATCH v4 0/4] "git apply" safety Junio C Hamano
2015-02-10 22:36     ` [PATCH v4 1/4] apply: reject input that touches outside the working area Junio C Hamano
2015-02-10 22:36     ` [PATCH v4 2/4] apply: do not read from the filesystem under --index Junio C Hamano
2015-02-10 22:36     ` [PATCH v4 3/4] apply: do not read from beyond a symbolic link Junio C Hamano
2015-02-10 22:36     ` [PATCH v4 4/4] apply: do not touch a file " Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqy4oepv59.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.