From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Josh Boyer <jwboyer@fedoraproject.org>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
twaugh@redhat.com, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] apply: refuse touching a file beyond symlink
Date: Fri, 30 Jan 2015 13:11:53 -0500 [thread overview]
Message-ID: <20150130181153.GA25513@peff.net> (raw)
In-Reply-To: <xmqqa911e2ot.fsf_-_@gitster.dls.corp.google.com>
On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote:
> +static int path_is_beyond_symlink(const char *name_)
> +{
> + struct strbuf name = STRBUF_INIT;
> +
> + strbuf_addstr(&name, name_);
> + do {
> + struct patch *previous;
> +
> + while (--name.len && name.buf[name.len] != '/')
> + ; /* scan backwards */
> + if (!name.len)
> + break;
I imagine it is impossible here for "name_" to be initially empty, but
it would make the backwards-scan loop go quite badly. Worth a comment or
an assert()?
> + name.buf[name.len] = '\0';
> + previous = in_fn_table(name.buf);
> + if (previous) {
> + if (!was_deleted(previous) &&
> + !to_be_deleted(previous) &&
> + previous->new_mode &&
> + S_ISLNK(previous->new_mode))
> + goto symlink_found;
> + } else if (check_index) {
> + int pos = cache_name_pos(name.buf, name.len);
> + if (0 <= pos &&
> + S_ISLNK(active_cache[pos]->ce_mode))
> + goto symlink_found;
> + } else {
> + struct stat st;
> + if (!lstat(name.buf, &st) && S_ISLNK(st.st_mode))
> + goto symlink_found;
> + }
> + } while (1);
> +
> + strbuf_release(&name);
> + return 0;
> +symlink_found:
> + strbuf_release(&name);
> + return 1;
Style nit, but might this be easier to follow the logic without the
gotos, by putting the setup and cleanup in a wrapper function and
returning directly from the main logic?
static int path_is_beyond_symlink(const char *name)
{
struct strbuf buf = STRBUF_INIT;
int ret;
strbuf_addstr(&buf, name);
ret = path_is_beyond_symlink_1(name);
strbuf_release(&buf);
return ret;
}
I can live with it either way, though.
> + if (!patch->is_delete && path_is_beyond_symlink(patch->new_name))
> + return error(_("affected file '%s' is beyond a symbolic link"),
> + patch->new_name);
Why does this not kick in when deleting a file? If it is not OK to
add across a symlink, why is it OK to delete? IOW, why should this test
fail:
diff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh
index 0a8de4a..f03b604 100755
--- a/t/t4122-apply-symlink-inside.sh
+++ b/t/t4122-apply-symlink-inside.sh
@@ -64,6 +64,7 @@ test_expect_success SYMLINKS 'do not follow symbolic link (setup)' '
>arch/x86_64/dir/file &&
git add arch/x86_64/dir/file &&
git diff HEAD >add_file.patch &&
+ git diff -R HEAD >del_file.patch &&
git reset --hard &&
rm -fr arch/x86_64/dir &&
@@ -111,7 +112,11 @@ test_expect_success SYMLINKS 'do not follow symbolic link (existing)' '
test_must_fail git apply --cached add_file.patch 2>error-ct-file &&
test_i18ngrep "beyond a symbolic link" error-ct-file &&
- test_must_fail git ls-files --error-unmatch arch/i386/dir
+ test_must_fail git ls-files --error-unmatch arch/i386/dir &&
+
+ >arch/i386/dir/file &&
+ test_must_fail git apply del_file.patch &&
+ test_path_is_file arch/i386/dir/file
'
test_done
> + test ! -e arch/x86_64/dir &&
> + test ! -e arch/i386/dir/file &&
Minor nit: use test_path_is_missing here (and elsewhere in the added
tests).
-Peff
next prev parent reply other threads:[~2015-01-30 18:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 16:29 patch-2.7.3 no longer applies relative symbolic link patches Josh Boyer
2015-01-26 16:32 ` Josh Boyer
2015-01-26 20:44 ` Linus Torvalds
2015-01-26 21:01 ` David Kastrup
2015-01-26 21:07 ` Josh Boyer
2015-01-26 21:30 ` Linus Torvalds
2015-01-26 21:35 ` Junio C Hamano
2015-01-26 21:50 ` Linus Torvalds
2015-01-27 15:47 ` Andreas Gruenbacher
2015-01-31 21:27 ` Andreas Gruenbacher
2015-01-26 22:15 ` Josh Boyer
2015-01-27 3:27 ` Junio C Hamano
2015-01-27 20:39 ` Junio C Hamano
2015-01-29 6:05 ` Junio C Hamano
2015-01-29 6:34 ` Junio C Hamano
2015-01-29 20:45 ` [PATCH] apply: refuse touching a file beyond symlink Junio C Hamano
2015-01-29 22:15 ` Stefan Beller
2015-01-29 23:48 ` [PATCH 2/1] apply: reject input that touches outside $cwd Junio C Hamano
2015-01-30 18:24 ` Jeff King
2015-01-30 19:07 ` Junio C Hamano
2015-01-30 19:16 ` Jeff King
2015-01-30 9:04 ` [PATCH] apply: refuse touching a file beyond symlink Christian Couder
2015-01-30 18:11 ` Jeff King [this message]
2015-01-30 19:42 ` Junio C Hamano
2015-01-30 19:46 ` Jeff King
2015-01-30 19:48 ` Junio C Hamano
2015-01-30 20:07 ` Jeff King
2015-01-30 20:32 ` Junio C Hamano
2015-01-30 20:11 ` Junio C Hamano
2015-01-30 20:16 ` Jeff King
2015-01-30 20:20 ` Junio C Hamano
2015-01-30 20:48 ` Jeff King
2015-01-30 21:10 ` Junio C Hamano
2015-01-30 21:50 ` Junio C Hamano
2015-01-27 15:26 ` patch-2.7.3 no longer applies relative symbolic link patches Andreas Gruenbacher
2015-01-27 15:26 ` Andreas Gruenbacher
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=20150130181153.GA25513@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=twaugh@redhat.com \
/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.