[PATCH] fsck: warn about '.' and '..' in trees

[PATCH] fsck: warn about '.' and '..' in trees

[Jeff King]

A tree with meta-paths like '.' or '..' does not work well
with git; the index will refuse to load it or check it out
to the filesystem (and even if we did not have that safety,
it would look like we were overwriting an untracked
directory). For the same reason, it is difficult to create
such a tree with regular git.

Let's warn about these dubious entries during fsck, just in
case somebody has created a bogus tree (and this also lets
us prevent them from propagating when transfer.fsckObjects
is set).

Signed-off-by: Jeff King <peff@peff.net>
---
I don't think this is happening in the wild, but I did see somebody
playing around with libgit2 make such a tree (and it is easy to do with
git-mktree, of course).

Technically one could use git with such a tree as long as you never ever
checked out the result, but I think it is sufficiently crazy that we
should probably detect it, just in case.

Should we also detect ".git" in the same way? It is similarly treated
specially by verify_path(), and its presence is likely to cause weird
errors.

 fsck.c          | 10 ++++++++++
 t/t1450-fsck.sh | 16 ++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/fsck.c b/fsck.c
index 7395ef6..31c9a51 100644
--- a/fsck.c
+++ b/fsck.c
@@ -142,6 +142,8 @@ static int fsck_tree(struct tree *item, int strict, fsck_error error_func)
 	int has_null_sha1 = 0;
 	int has_full_path = 0;
 	int has_empty_name = 0;
+	int has_dot = 0;
+	int has_dotdot = 0;
 	int has_zero_pad = 0;
 	int has_bad_modes = 0;
 	int has_dup_entries = 0;
@@ -168,6 +170,10 @@ static int fsck_tree(struct tree *item, int strict, fsck_error error_func)
 			has_full_path = 1;
 		if (!*name)
 			has_empty_name = 1;
+		if (!strcmp(name, "."))
+			has_dot = 1;
+		if (!strcmp(name, ".."))
+			has_dotdot = 1;
 		has_zero_pad |= *(char *)desc.buffer == '0';
 		update_tree_entry(&desc);
 
@@ -217,6 +223,10 @@ static int fsck_tree(struct tree *item, int strict, fsck_error error_func)
 		retval += error_func(&item->object, FSCK_WARN, "contains full pathnames");
 	if (has_empty_name)
 		retval += error_func(&item->object, FSCK_WARN, "contains empty pathname");
+	if (has_dot)
+		retval += error_func(&item->object, FSCK_WARN, "contains '.'");
+	if (has_dotdot)
+		retval += error_func(&item->object, FSCK_WARN, "contains '..'");
 	if (has_zero_pad)
 		retval += error_func(&item->object, FSCK_WARN, "contains zero-padded file modes");
 	if (has_bad_modes)
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 08aa24c..0b5c30b 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -237,4 +237,20 @@ test_expect_success 'fsck notices submodule entry pointing to null sha1' '
 	)
 '
 
+test_expect_success 'fsck notices "." and ".." in trees' '
+	(
+		git init dots &&
+		cd dots &&
+		blob=$(echo foo | git hash-object -w --stdin) &&
+		tab=$(printf "\\t") &&
+		git mktree <<-EOF &&
+		100644 blob $blob$tab.
+		100644 blob $blob$tab..
+		EOF
+		git fsck 2>out &&
+		cat out &&
+		grep "warning.*\\." out
+	)
+'
+
 test_done
-- 
1.8.0.207.gdf2154c

Re: [PATCH] fsck: warn about '.' and '..' in trees

[Nguyen Thai Ngoc Duy]

On Wed, Nov 28, 2012 at 9:27 AM, Jeff King <peff@peff.net> wrote:
> A tree with meta-paths like '.' or '..' does not work well
> with git; the index will refuse to load it or check it out
> to the filesystem (and even if we did not have that safety,
> it would look like we were overwriting an untracked
> directory). For the same reason, it is difficult to create
> such a tree with regular git.
>
> Let's warn about these dubious entries during fsck, just in
> case somebody has created a bogus tree (and this also lets
> us prevent them from propagating when transfer.fsckObjects
> is set).
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I don't think this is happening in the wild, but I did see somebody
> playing around with libgit2 make such a tree (and it is easy to do with
> git-mktree, of course).
>
> Technically one could use git with such a tree as long as you never ever
> checked out the result, but I think it is sufficiently crazy that we
> should probably detect it, just in case.

Can we declare "." and ".." illegal? There's no room for extension in
tree objects and I'm thinking of using maybe "." entry as an extension
indicator. Not sure if it works, old gits may attempt to checkout "."
entries and fail...
-- 
Duy

Re: [PATCH] fsck: warn about '.' and '..' in trees

[Jeff King]

On Wed, Nov 28, 2012 at 11:22:20AM +0700, Nguyen Thai Ngoc Duy wrote:

> > I don't think this is happening in the wild, but I did see somebody
> > playing around with libgit2 make such a tree (and it is easy to do with
> > git-mktree, of course).
> >
> > Technically one could use git with such a tree as long as you never ever
> > checked out the result, but I think it is sufficiently crazy that we
> > should probably detect it, just in case.
> 
> Can we declare "." and ".." illegal? There's no room for extension in
> tree objects and I'm thinking of using maybe "." entry as an extension
> indicator. Not sure if it works, old gits may attempt to checkout "."
> entries and fail...

Yeah, current git fails pretty hard. Try this:

  check() {
    git init -q "$1" &&
    (cd "$1" &&
     blob=$(echo foo | git hash-object -w --stdin) &&
     tree=$(printf '100644 blob %s\t%s' $blob "$2" | git mktree) &&
     commit=$(echo foo | git commit-tree $tree) &&
     git update-ref HEAD $commit &&
     git clone -q . clone
    )
  }

  $ check dot .
  error: Invalid path '.'

  $ check dotdot ..
  error: Updating '..' would lose untracked files in it

  $ check dotgit .git
  error: Updating '.git' would lose untracked files in it

Interesting that we detect the first one while reading into the cache,
but apparently try much harder to checkout on the latter two. Not sure I
want to try "git checkout -f". :)

-Peff

Re: [PATCH] fsck: warn about '.' and '..' in trees

[Jeff King]

On Tue, Nov 27, 2012 at 11:32:16PM -0500, Jeff King wrote:

>   $ check dot .
>   error: Invalid path '.'
> 
>   $ check dotdot ..
>   error: Updating '..' would lose untracked files in it
> 
>   $ check dotgit .git
>   error: Updating '.git' would lose untracked files in it
> 
> Interesting that we detect the first one while reading into the cache,
> but apparently try much harder to checkout on the latter two. Not sure I
> want to try "git checkout -f". :)

Actually, I take it back. The "untracked files" check comes _first_, and
if you do "-f", we end up in the verify_path check when trying to pull
the tree into the index. So I think the way git handles it makes sense.

-Peff