fsck: BAD_FILEMODE diagnostic broken / never triggers

fsck: BAD_FILEMODE diagnostic broken / never triggers

[Xavier Morel]

While looking at git's handling of invalid objects, I stumbled upon
git apparently not caring much about file mode values, except for the
following requirements:

- must be non-empty (badTree)
- must be octal (badTree)
- should not be zero-padded (zeroPaddedFilemode)

Looking at tree-walk this is obvious from decode_tree_entry: it calls
canon_mode, which

- checks the S_IFMT exactly, and falls back on 160000 (S_IFGITLINK)
  for cases other than S_ISREG, S_ISLNK, or S_ISDIR
- returns the corresponding S_IF (with the access modes unset) for all 
  cases other than S_ISREG, for which it returns 755 if S_IXUSR is set,
  otherwise 644

However looking at fsck_tree, it does have a fair amount of code to
validate entry modes and a dedicated message id for this (BAD_FILEMODE
/ badFilemode), it even has a code path for legacy entries with
S_IWGRP set (extensively documented under `git fsck --strict`).

I guess, over time mode canonicalisation has slowly creeped earlier
the tree-parsing code, and (seemingly for several years) it has been
occurring before "git fsck" gets tree entry information, so git fsck
simply can not see invalid entry modes?

Reproduction:

- create an empty git repository
- create tree for (or with) any possible entry type value
- run `git fsck --strict --no-dangling`

Expected:

all the trees except the 5 with valid filemodes should be flagged

Observed:

> git fsck --strict --no-dangling
Checking object directories: 100% (256/256), done.
notice: HEAD points to an unborn branch (master)
notice: No default references

Script to generate one tree for each filemode between 1 and 777777
(inclusive), can be run from a (non-bare) repository root, beware that
the resulting repository takes about 1GB.


from hashlib import sha1
from pathlib import Path
from zlib import compress

def hash_object(type, content):
    obj = b"%s %d\0%s" % (type.encode(), len(content), content)
    oid = sha1(obj).hexdigest()

    e_dir = GIT_ROOT / 'objects' / oid[:2]
    e_dir.mkdir(exist_ok=True, parents=True)

    e = e_dir / oid[2:]
    if not e.exists():
        e.write_bytes(compress(obj))

    return oid

# technically S_IFMT caps out at 200_000 - 1, but get_mode doesn't
# actually have a limit
MAX_ENTRY = 0o777_777
if __name__ == '__main__':
    GIT_ROOT = Path.cwd() / '.git'
    assert GIT_ROOT.is_dir()
    
    blob_hex = hash_object('blob', b"")
    blob_oid = bytes.fromhex(blob_hex)
    print("empty blob", blob_hex)

    tree_hex = hash_object("tree", b"100644 empty_blob\0" + blob_oid)
    tree_oid = bytes.fromhex(tree_hex)
    print("base tree", tree_hex)

    for mode in range(1, MAX_ENTRY+1):
        print(f"\r{mode:06o}/{MAX_ENTRY:o}", end=' ')
        tree = b"%o x\0%s" % (
            mode,
            tree_oid if (mode & 0o170_000) == 0o040_000 else blob_oid,
        )
        h = hash_object("tree", tree)
        print("=", h, end='', flush=True)

Re: fsck: BAD_FILEMODE diagnostic broken / never triggers

[Jeff King]

On Sat, Aug 06, 2022 at 03:43:56PM +0200, Xavier Morel wrote:

> However looking at fsck_tree, it does have a fair amount of code to
> validate entry modes and a dedicated message id for this (BAD_FILEMODE
> / badFilemode), it even has a code path for legacy entries with
> S_IWGRP set (extensively documented under `git fsck --strict`).
> 
> I guess, over time mode canonicalisation has slowly creeped earlier
> the tree-parsing code, and (seemingly for several years) it has been
> occurring before "git fsck" gets tree entry information, so git fsck
> simply can not see invalid entry modes?

Yes, I think you're right. I didn't bisect, but I suspect this goes back
to 7146e66f08 (tree-walk: finally switch over tree descriptors to
contain a pre-parsed entry, 2014-02-06).

We probably need to provide version of decode_tree_entry() which gives
the non-canonical mode, and to call it from fsck.

-Peff

Re: fsck: BAD_FILEMODE diagnostic broken / never triggers

[Jeff King]

On Tue, Aug 09, 2022 at 06:48:51PM -0400, Jeff King wrote:

> On Sat, Aug 06, 2022 at 03:43:56PM +0200, Xavier Morel wrote:
> 
> > However looking at fsck_tree, it does have a fair amount of code to
> > validate entry modes and a dedicated message id for this (BAD_FILEMODE
> > / badFilemode), it even has a code path for legacy entries with
> > S_IWGRP set (extensively documented under `git fsck --strict`).
> > 
> > I guess, over time mode canonicalisation has slowly creeped earlier
> > the tree-parsing code, and (seemingly for several years) it has been
> > occurring before "git fsck" gets tree entry information, so git fsck
> > simply can not see invalid entry modes?
> 
> Yes, I think you're right. I didn't bisect, but I suspect this goes back
> to 7146e66f08 (tree-walk: finally switch over tree descriptors to
> contain a pre-parsed entry, 2014-02-06).

Hmm, actually, I think this may have been broken since the beginning of
fsck. At least I could not find a version for which the test below
behaves as expected.

> We probably need to provide version of decode_tree_entry() which gives
> the non-canonical mode, and to call it from fsck.

Perhaps something like the patch below.

Note that these are treated with a severity of "warning", so fsck won't
give a non-zero exit. I think it still enough for transfer.fsckObjects
to mark them. I kind of wonder if fixing this at this point might create
more problems than it solves though (e.g., if people have broken modes
in historical objects that servers may now reject).

---
diff --git a/fsck.c b/fsck.c
index dd4822ba1b..b3da1d68c0 100644
--- a/fsck.c
+++ b/fsck.c
@@ -308,7 +308,7 @@ static int fsck_walk_tree(struct tree *tree, void *data, struct fsck_options *op
 		return -1;
 
 	name = fsck_get_object_name(options, &tree->object.oid);
-	if (init_tree_desc_gently(&desc, tree->buffer, tree->size))
+	if (init_tree_desc_gently(&desc, tree->buffer, tree->size, 0))
 		return -1;
 	while (tree_entry_gently(&desc, &entry)) {
 		struct object *obj;
@@ -578,7 +578,7 @@ static int fsck_tree(const struct object_id *tree_oid,
 	const char *o_name;
 	struct name_stack df_dup_candidates = { NULL };
 
-	if (init_tree_desc_gently(&desc, buffer, size)) {
+	if (init_tree_desc_gently(&desc, buffer, size, TREE_DESC_RAW_MODES)) {
 		retval += report(options, tree_oid, OBJ_TREE,
 				 FSCK_MSG_BAD_TREE,
 				 "cannot be parsed as a tree");
diff --git a/packfile.c b/packfile.c
index 6b0eb9048e..5ae3ce8ea9 100644
--- a/packfile.c
+++ b/packfile.c
@@ -2231,7 +2231,7 @@ static int add_promisor_object(const struct object_id *oid,
 		struct tree *tree = (struct tree *)obj;
 		struct tree_desc desc;
 		struct name_entry entry;
-		if (init_tree_desc_gently(&desc, tree->buffer, tree->size))
+		if (init_tree_desc_gently(&desc, tree->buffer, tree->size, 0))
 			/*
 			 * Error messages are given when packs are
 			 * verified, so do not print any here.
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index ab7f31f1dc..d2051e0fda 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -364,6 +364,17 @@ test_expect_success 'tree entry with type mismatch' '
 	test_i18ngrep ! "dangling blob" out
 '
 
+test_expect_success 'tree entry with bogus mode' '
+	test_when_finished "remove_object \$blob" &&
+	test_when_finished "remove_object \$tree" &&
+	blob=$(echo blob | git hash-object -w --stdin) &&
+	blob_oct=$(echo $blob | hex2oct) &&
+	tree=$(printf "100000 foo\0${blob_oct}" |
+	       git hash-object -t tree --stdin -w --literally) &&
+	git fsck 2>err &&
+	grep "$tree: badFilemode" err
+'
+
 test_expect_success 'tag pointing to nonexistent' '
 	badoid=$(test_oid deadbeef) &&
 	cat >invalid-tag <<-EOF &&
diff --git a/tree-walk.c b/tree-walk.c
index 506234b4b8..74f4d710e8 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -47,17 +47,20 @@ static int decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned l
 
 	/* Initialize the descriptor entry */
 	desc->entry.path = path;
-	desc->entry.mode = canon_mode(mode);
+	desc->entry.mode = (desc->flags & TREE_DESC_RAW_MODES) ? mode : canon_mode(mode);
 	desc->entry.pathlen = len - 1;
 	oidread(&desc->entry.oid, (const unsigned char *)path + len);
 
 	return 0;
 }
 
-static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer, unsigned long size, struct strbuf *err)
+static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer,
+				   unsigned long size, struct strbuf *err,
+				   enum tree_desc_flags flags)
 {
 	desc->buffer = buffer;
 	desc->size = size;
+	desc->flags = flags;
 	if (size)
 		return decode_tree_entry(desc, buffer, size, err);
 	return 0;
@@ -66,15 +69,16 @@ static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer, u
 void init_tree_desc(struct tree_desc *desc, const void *buffer, unsigned long size)
 {
 	struct strbuf err = STRBUF_INIT;
-	if (init_tree_desc_internal(desc, buffer, size, &err))
+	if (init_tree_desc_internal(desc, buffer, size, &err, 0))
 		die("%s", err.buf);
 	strbuf_release(&err);
 }
 
-int init_tree_desc_gently(struct tree_desc *desc, const void *buffer, unsigned long size)
+int init_tree_desc_gently(struct tree_desc *desc, const void *buffer, unsigned long size,
+			  enum tree_desc_flags flags)
 {
 	struct strbuf err = STRBUF_INIT;
-	int result = init_tree_desc_internal(desc, buffer, size, &err);
+	int result = init_tree_desc_internal(desc, buffer, size, &err, flags);
 	if (result)
 		error("%s", err.buf);
 	strbuf_release(&err);
diff --git a/tree-walk.h b/tree-walk.h
index a5058469e9..6305d53150 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -34,6 +34,11 @@ struct tree_desc {
 
 	/* counts the number of bytes left in the `buffer`. */
 	unsigned int size;
+
+	/* option flags passed via init_tree_desc_gently() */
+	enum tree_desc_flags {
+		TREE_DESC_RAW_MODES = (1 << 0),
+	} flags;
 };
 
 /**
@@ -79,7 +84,8 @@ int update_tree_entry_gently(struct tree_desc *);
  */
 void init_tree_desc(struct tree_desc *desc, const void *buf, unsigned long size);
 
-int init_tree_desc_gently(struct tree_desc *desc, const void *buf, unsigned long size);
+int init_tree_desc_gently(struct tree_desc *desc, const void *buf, unsigned long size,
+			  enum tree_desc_flags flags);
 
 /*
  * Visit the next entry in a tree. Returns 1 when there are more entries

Re: fsck: BAD_FILEMODE diagnostic broken / never triggers

[Xavier Morel]

>> We probably need to provide version of decode_tree_entry() which gives
>> the non-canonical mode, and to call it from fsck.

That makes sense.

> Perhaps something like the patch below.

I fear I'm really not able to judge so I'll let you fine folks decide on what to do.

> Note that these are treated with a severity of "warning", so fsck won't
> give a non-zero exit.

Yeah from what I understand it is classified as a warning already
(just not emitted), like the zero padded filemodes. And that can be
upgraded to error using fsck.msgid=error so shouldn't be an issue.

> I think it still enough for transfer.fsckObjects
> to mark them. I kind of wonder if fixing this at this point might create
> more problems than it solves though (e.g., if people have broken modes
> in historical objects that servers may now reject).

Maybe downgrade to info or ignore by default then? It might still be
an issue for people who wilfully upgraded the diagnostic to error
hoping to catch the, but hopefully if they did that they'd rather get
the notice later than never?

That's pretty much the `-Werror` problem (or one of them anyway)

Re: fsck: BAD_FILEMODE diagnostic broken / never triggers

[Jeff King]

On Wed, Aug 10, 2022 at 05:01:34PM +0200, Xavier Morel wrote:

> > Note that these are treated with a severity of "warning", so fsck won't
> > give a non-zero exit.
> 
> Yeah from what I understand it is classified as a warning already
> (just not emitted), like the zero padded filemodes. And that can be
> upgraded to error using fsck.msgid=error so shouldn't be an issue.

Right.

> > I think it still enough for transfer.fsckObjects
> > to mark them. I kind of wonder if fixing this at this point might create
> > more problems than it solves though (e.g., if people have broken modes
> > in historical objects that servers may now reject).
> 
> Maybe downgrade to info or ignore by default then? It might still be
> an issue for people who wilfully upgraded the diagnostic to error
> hoping to catch the, but hopefully if they did that they'd rather get
> the notice later than never?

Yeah, that may be a sensible resolution. All things being equal I think
"warning" is the right level, but out of caution and the historical
precedent, maybe downgrading it to "info" is justified.

It should be easy to work that into the patch I showed earlier.

-Peff

[PATCH 0/3] actually detect bad file modes in fsck

[Jeff King]

On Wed, Aug 10, 2022 at 04:04:17PM -0400, Jeff King wrote:

> > Maybe downgrade to info or ignore by default then? It might still be
> > an issue for people who wilfully upgraded the diagnostic to error
> > hoping to catch the, but hopefully if they did that they'd rather get
> > the notice later than never?
> 
> Yeah, that may be a sensible resolution. All things being equal I think
> "warning" is the right level, but out of caution and the historical
> precedent, maybe downgrading it to "info" is justified.
> 
> It should be easy to work that into the patch I showed earlier.

OK, so here are cleaned-up patches to do that.

  [1/3]: tree-walk: add a mechanism for getting non-canonicalized modes
  [2/3]: fsck: actually detect bad file modes in trees
  [3/3]: fsck: downgrade tree badFilemode to "info"

 fsck.c                          |  4 ++--
 fsck.h                          |  2 +-
 packfile.c                      |  2 +-
 t/t1450-fsck.sh                 | 14 ++++++++++++++
 t/t5504-fetch-receive-strict.sh | 17 +++++++++++++++++
 tree-walk.c                     | 14 +++++++++-----
 tree-walk.h                     |  8 +++++++-
 7 files changed, 51 insertions(+), 10 deletions(-)

-Peff

[PATCH 1/3] tree-walk: add a mechanism for getting non-canonicalized modes

[Jeff King]

When using init_tree_desc() and tree_entry() to iterate over a tree, we
always canonicalize the modes coming out of the tree. This is a good
thing to prevent bugs or oddities in normal code paths, but it's
counter-productive for tools like fsck that want to see the exact
contents.

We can address this by adding an option to avoid the extra
canonicalization. A few notes on the implementation:

  - I've attached the new option to the tree_desc struct itself. The
    actual code change is in decode_tree_entry(), which is in turn
    called by the public update_tree_entry(), tree_entry(), and
    init_tree_desc() functions, plus their "gently" counterparts.

    By letting it ride along in the struct, we can avoid changing the
    signature of those functions, which are called many times. Plus it's
    conceptually simpler: you really want a particular iteration of a
    tree to be "raw" or not, rather than individual calls.

  - We still have to set the new option somewhere. The struct is
    initialized by init_tree_desc(). I added the new flags field only to
    the "gently" version. That avoids disturbing the much more numerous
    non-gentle callers, and it makes sense that anybody being careful
    about looking at raw modes would also be careful about bogus trees
    (i.e., the caller will be something like fsck in the first place).

Signed-off-by: Jeff King <peff@peff.net>
---
 fsck.c      |  4 ++--
 packfile.c  |  2 +-
 tree-walk.c | 14 +++++++++-----
 tree-walk.h |  8 +++++++-
 4 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/fsck.c b/fsck.c
index dd4822ba1b..5acc982a7c 100644
--- a/fsck.c
+++ b/fsck.c
@@ -308,7 +308,7 @@ static int fsck_walk_tree(struct tree *tree, void *data, struct fsck_options *op
 		return -1;
 
 	name = fsck_get_object_name(options, &tree->object.oid);
-	if (init_tree_desc_gently(&desc, tree->buffer, tree->size))
+	if (init_tree_desc_gently(&desc, tree->buffer, tree->size, 0))
 		return -1;
 	while (tree_entry_gently(&desc, &entry)) {
 		struct object *obj;
@@ -578,7 +578,7 @@ static int fsck_tree(const struct object_id *tree_oid,
 	const char *o_name;
 	struct name_stack df_dup_candidates = { NULL };
 
-	if (init_tree_desc_gently(&desc, buffer, size)) {
+	if (init_tree_desc_gently(&desc, buffer, size, 0)) {
 		retval += report(options, tree_oid, OBJ_TREE,
 				 FSCK_MSG_BAD_TREE,
 				 "cannot be parsed as a tree");
diff --git a/packfile.c b/packfile.c
index 6b0eb9048e..5ae3ce8ea9 100644
--- a/packfile.c
+++ b/packfile.c
@@ -2231,7 +2231,7 @@ static int add_promisor_object(const struct object_id *oid,
 		struct tree *tree = (struct tree *)obj;
 		struct tree_desc desc;
 		struct name_entry entry;
-		if (init_tree_desc_gently(&desc, tree->buffer, tree->size))
+		if (init_tree_desc_gently(&desc, tree->buffer, tree->size, 0))
 			/*
 			 * Error messages are given when packs are
 			 * verified, so do not print any here.
diff --git a/tree-walk.c b/tree-walk.c
index 506234b4b8..74f4d710e8 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -47,17 +47,20 @@ static int decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned l
 
 	/* Initialize the descriptor entry */
 	desc->entry.path = path;
-	desc->entry.mode = canon_mode(mode);
+	desc->entry.mode = (desc->flags & TREE_DESC_RAW_MODES) ? mode : canon_mode(mode);
 	desc->entry.pathlen = len - 1;
 	oidread(&desc->entry.oid, (const unsigned char *)path + len);
 
 	return 0;
 }
 
-static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer, unsigned long size, struct strbuf *err)
+static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer,
+				   unsigned long size, struct strbuf *err,
+				   enum tree_desc_flags flags)
 {
 	desc->buffer = buffer;
 	desc->size = size;
+	desc->flags = flags;
 	if (size)
 		return decode_tree_entry(desc, buffer, size, err);
 	return 0;
@@ -66,15 +69,16 @@ static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer, u
 void init_tree_desc(struct tree_desc *desc, const void *buffer, unsigned long size)
 {
 	struct strbuf err = STRBUF_INIT;
-	if (init_tree_desc_internal(desc, buffer, size, &err))
+	if (init_tree_desc_internal(desc, buffer, size, &err, 0))
 		die("%s", err.buf);
 	strbuf_release(&err);
 }
 
-int init_tree_desc_gently(struct tree_desc *desc, const void *buffer, unsigned long size)
+int init_tree_desc_gently(struct tree_desc *desc, const void *buffer, unsigned long size,
+			  enum tree_desc_flags flags)
 {
 	struct strbuf err = STRBUF_INIT;
-	int result = init_tree_desc_internal(desc, buffer, size, &err);
+	int result = init_tree_desc_internal(desc, buffer, size, &err, flags);
 	if (result)
 		error("%s", err.buf);
 	strbuf_release(&err);
diff --git a/tree-walk.h b/tree-walk.h
index a5058469e9..6305d53150 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -34,6 +34,11 @@ struct tree_desc {
 
 	/* counts the number of bytes left in the `buffer`. */
 	unsigned int size;
+
+	/* option flags passed via init_tree_desc_gently() */
+	enum tree_desc_flags {
+		TREE_DESC_RAW_MODES = (1 << 0),
+	} flags;
 };
 
 /**
@@ -79,7 +84,8 @@ int update_tree_entry_gently(struct tree_desc *);
  */
 void init_tree_desc(struct tree_desc *desc, const void *buf, unsigned long size);
 
-int init_tree_desc_gently(struct tree_desc *desc, const void *buf, unsigned long size);
+int init_tree_desc_gently(struct tree_desc *desc, const void *buf, unsigned long size,
+			  enum tree_desc_flags flags);
 
 /*
  * Visit the next entry in a tree. Returns 1 when there are more entries
-- 
2.37.1.917.gf0c714241f

[PATCH 2/3] fsck: actually detect bad file modes in trees

[Jeff King]

We use the normal tree_desc code to iterate over trees in fsck, meaning
we only see the canonicalized modes it returns. And hence we'd never see
anything unexpected, since it will coerce literally any garbage into one
of our normal and accepted modes.

We can use the new RAW_MODES flag to see the real modes, and then use
the existing code to actually analyze them. The existing code is written
as allow-known-good, so there's not much point in testing a variety of
breakages. The one tested here should be S_IFREG but with nonsense
permissions.

Do note that the error-reporting here isn't great. We don't mention the
specific bad mode, but just that the tree has one or more broken modes.
But when you go to look at it with "git ls-tree", we'll report the
canonicalized mode! This isn't ideal, but given that this should come up
rarely, and that any number of other tree corruptions might force you
into looking at the binary bytes via "cat-file", it's not the end of the
world. And it's something we can improve on top later if we choose.

Reported-by: Xavier Morel <xavier.morel@masklinn.net>
Signed-off-by: Jeff King <peff@peff.net>
---
 fsck.c          |  2 +-
 t/t1450-fsck.sh | 14 ++++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/fsck.c b/fsck.c
index 5acc982a7c..b3da1d68c0 100644
--- a/fsck.c
+++ b/fsck.c
@@ -578,7 +578,7 @@ static int fsck_tree(const struct object_id *tree_oid,
 	const char *o_name;
 	struct name_stack df_dup_candidates = { NULL };
 
-	if (init_tree_desc_gently(&desc, buffer, size, 0)) {
+	if (init_tree_desc_gently(&desc, buffer, size, TREE_DESC_RAW_MODES)) {
 		retval += report(options, tree_oid, OBJ_TREE,
 				 FSCK_MSG_BAD_TREE,
 				 "cannot be parsed as a tree");
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index ab7f31f1dc..53c2aa10b7 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -364,6 +364,20 @@ test_expect_success 'tree entry with type mismatch' '
 	test_i18ngrep ! "dangling blob" out
 '
 
+test_expect_success 'tree entry with bogus mode' '
+	test_when_finished "remove_object \$blob" &&
+	test_when_finished "remove_object \$tree" &&
+	blob=$(echo blob | git hash-object -w --stdin) &&
+	blob_oct=$(echo $blob | hex2oct) &&
+	tree=$(printf "100000 foo\0${blob_oct}" |
+	       git hash-object -t tree --stdin -w --literally) &&
+	git fsck 2>err &&
+	cat >expect <<-EOF &&
+	warning in tree $tree: badFilemode: contains bad file modes
+	EOF
+	test_cmp expect err
+'
+
 test_expect_success 'tag pointing to nonexistent' '
 	badoid=$(test_oid deadbeef) &&
 	cat >invalid-tag <<-EOF &&
-- 
2.37.1.917.gf0c714241f

Re: [PATCH 2/3] fsck: actually detect bad file modes in trees

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> We use the normal tree_desc code to iterate over trees in fsck, meaning
> we only see the canonicalized modes it returns. And hence we'd never see
> anything unexpected, since it will coerce literally any garbage into one
> of our normal and accepted modes.

Wow.  I did know canon_mode() deliberately discarding the extra
permission bits on trees and blobs, but it was that bad to mark
whatever it does not understand as a gitlink.  That is simply
horrible.

> -	if (init_tree_desc_gently(&desc, buffer, size, 0)) {
> +	if (init_tree_desc_gently(&desc, buffer, size, TREE_DESC_RAW_MODES)) {
>  		retval += report(options, tree_oid, OBJ_TREE,
>  				 FSCK_MSG_BAD_TREE,
>  				 "cannot be parsed as a tree");

OK, so we'll let desc.entry.mode carry whatever bogus bit pattern we
got out of buffer and the downstream code already knows what to do
with them.  That's a clean and minimum way to do this.

Thanks.

> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
> index ab7f31f1dc..53c2aa10b7 100755
> --- a/t/t1450-fsck.sh
> +++ b/t/t1450-fsck.sh
> @@ -364,6 +364,20 @@ test_expect_success 'tree entry with type mismatch' '
>  	test_i18ngrep ! "dangling blob" out
>  '
>  
> +test_expect_success 'tree entry with bogus mode' '
> +	test_when_finished "remove_object \$blob" &&
> +	test_when_finished "remove_object \$tree" &&
> +	blob=$(echo blob | git hash-object -w --stdin) &&
> +	blob_oct=$(echo $blob | hex2oct) &&
> +	tree=$(printf "100000 foo\0${blob_oct}" |
> +	       git hash-object -t tree --stdin -w --literally) &&
> +	git fsck 2>err &&
> +	cat >expect <<-EOF &&
> +	warning in tree $tree: badFilemode: contains bad file modes
> +	EOF
> +	test_cmp expect err
> +'
> +
>  test_expect_success 'tag pointing to nonexistent' '
>  	badoid=$(test_oid deadbeef) &&
>  	cat >invalid-tag <<-EOF &&

Re: [PATCH 2/3] fsck: actually detect bad file modes in trees

[Jeff King]

On Wed, Aug 10, 2022 at 02:35:32PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > We use the normal tree_desc code to iterate over trees in fsck, meaning
> > we only see the canonicalized modes it returns. And hence we'd never see
> > anything unexpected, since it will coerce literally any garbage into one
> > of our normal and accepted modes.
> 
> Wow.  I did know canon_mode() deliberately discarding the extra
> permission bits on trees and blobs, but it was that bad to mark
> whatever it does not understand as a gitlink.  That is simply
> horrible.

Yeah, I noticed that, as well. It might actually be reasonable to put a
die() at the end of that canon_mode() function. It's rather unfriendly,
but then, treating nonsense as a gitlink is likely to just result in the
caller ending up aborting anyway.

Outside the scope of my patch, though. :)

-Peff

Re: [PATCH 2/3] fsck: actually detect bad file modes in trees

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Outside the scope of my patch, though. :)

Absolutely.

[PATCH 3/3] fsck: downgrade tree badFilemode to "info"

[Jeff King]

The previous commit un-broke the "badFileMode" check; before then it was
literally testing nothing. And as far as I can tell, it has been so
since the very initial version of fsck.

The current severity of "badFileMode" is just "warning". But in the
--strict mode used by transfer.fsckObjects, that is elevated to an
error. This will potentially cause hassle for users, because historical
objects with bad modes will suddenly start causing pushes to many server
operators to be rejected.

At the same time, these bogus modes aren't actually a big risk. Because
we canonicalize them everywhere besides fsck, they can't cause too much
mischief in the real world. The worst thing you can do is end up with
two almost-identical trees that have different hashes but are
interpreted the same. That will generally cause things to be inefficient
rather than wrong, and is a bug somebody working on a Git implementation
would want to fix, but probably not worth inconveniencing users by
refusing to push or fetch.

So let's downgrade this to "info" by default, which is our setting for
"mention this when fscking, but don't ever reject, even under strict
mode". If somebody really wants to be paranoid, they can still adjust
the level using config.

Suggested-by: Xavier Morel <xavier.morel@masklinn.net>
Signed-off-by: Jeff King <peff@peff.net>
---
 fsck.h                          |  2 +-
 t/t5504-fetch-receive-strict.sh | 17 +++++++++++++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/fsck.h b/fsck.h
index d07f7a2459..6f801e53b1 100644
--- a/fsck.h
+++ b/fsck.h
@@ -56,7 +56,6 @@ enum fsck_msg_type {
 	FUNC(GITMODULES_PATH, ERROR) \
 	FUNC(GITMODULES_UPDATE, ERROR) \
 	/* warnings */ \
-	FUNC(BAD_FILEMODE, WARN) \
 	FUNC(EMPTY_NAME, WARN) \
 	FUNC(FULL_PATHNAME, WARN) \
 	FUNC(HAS_DOT, WARN) \
@@ -66,6 +65,7 @@ enum fsck_msg_type {
 	FUNC(ZERO_PADDED_FILEMODE, WARN) \
 	FUNC(NUL_IN_COMMIT, WARN) \
 	/* infos (reported as warnings, but ignored by default) */ \
+	FUNC(BAD_FILEMODE, INFO) \
 	FUNC(GITMODULES_PARSE, INFO) \
 	FUNC(GITIGNORE_SYMLINK, INFO) \
 	FUNC(GITATTRIBUTES_SYMLINK, INFO) \
diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
index b0b795aca9..ac4099ca89 100755
--- a/t/t5504-fetch-receive-strict.sh
+++ b/t/t5504-fetch-receive-strict.sh
@@ -352,4 +352,21 @@ test_expect_success \
 	grep "Cannot demote unterminatedheader" act
 '
 
+test_expect_success 'badFilemode is not a strict error' '
+	git init --bare badmode.git &&
+	tree=$(
+		cd badmode.git &&
+		blob=$(echo blob | git hash-object -w --stdin | hex2oct) &&
+		printf "123456 foo\0${blob}" |
+		git hash-object -t tree --stdin -w --literally
+	) &&
+
+	rm -rf dst.git &&
+	git init --bare dst.git &&
+	git -C dst.git config transfer.fsckObjects true &&
+
+	git -C badmode.git push ../dst.git $tree:refs/tags/tree 2>err &&
+	grep "$tree: badFilemode" err
+'
+
 test_done
-- 
2.37.1.917.gf0c714241f

Re: [PATCH 3/3] fsck: downgrade tree badFilemode to "info"

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ... That will generally cause things to be inefficient
> rather than wrong, and is a bug somebody working on a Git implementation
> would want to fix, but probably not worth inconveniencing users by
> refusing to push or fetch.
>
> So let's downgrade this to "info" by default, which is our setting for
> "mention this when fscking, but don't ever reject, even under strict
> mode". If somebody really wants to be paranoid, they can still adjust
> the level using config.

IIRC, I heard that every reimplementation of Git got the tree entry
wrong one way or another at least once.  I think this is prudent.

I was almost sure that before we "unified" the codepath for normal
tree reading and the one used for fsck in a mistaken way, which was
fixed in this series, we were catching these anomalous mode bits,
but the suspected regression is too long ago that it does not make a
practical difference if it was always broken or it was broken long
time ago.  The risk to start complaining on existing projects is the
same either way.

Thanks for working on this series.

Re: [PATCH 3/3] fsck: downgrade tree badFilemode to "info"

[Jeff King]

On Wed, Aug 10, 2022 at 03:08:14PM -0700, Junio C Hamano wrote:

> I was almost sure that before we "unified" the codepath for normal
> tree reading and the one used for fsck in a mistaken way, which was
> fixed in this series, we were catching these anomalous mode bits,
> but the suspected regression is too long ago that it does not make a
> practical difference if it was always broken or it was broken long
> time ago.  The risk to start complaining on existing projects is the
> same either way.

I agree with the "it was so long ago it does not matter", but for the
sake of posterity, here's what my digging found:

  - we got the mode fsck checks in 64071805ed (git-fsck-cache: be
    stricter about "tree" objects, 2005-07-27), though there is a proto
    version that is even a little older. Back then we were using a
    linked list to hold the parsed tree entries (!), but it was parsed
    by a central spot in parse_tree_buffer().

  - that linked list code went away in 15b5536ee4 (Remove last vestiges
    of generic tree_entry_list, 2006-05-29). But...

  - ...by then we already had 1b0c7174a1 (tree/diff header cleanup.,
    2006-03-29), which had tree_entry_extract(). And that commit
    introduced canon_mode, including the same "set unexpected things to
    a default", though of course back then it waas S_IFDIR since
    gitlinks didn't exist. ;)

  - that canon_mode() was just a rename from DIFF_FILE_CANON_MODE(),
    which ultimately came from 67574c403f ([PATCH] diff: mode bits
    fixes, 2005-06-01)

So some form of canon_mode() does predate the fsck checks, but I _think_
the fsck code was using the old linked-list version until 15b5536ee4,
and would not have been affected. So yes, there were probably 10 months
in 2005-2006 where we would have detected these. :)

Again, probably not important, but it was interesting for me at least to
see the evolution of the tree code. Most of those changes predate my
involvement with the code.

-Peff

Re: [PATCH 3/3] fsck: downgrade tree badFilemode to "info"

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I agree with the "it was so long ago it does not matter", but for the
> sake of posterity, here's what my digging found:
> ...

That's indeed an ancient history.  Thanks for a funny find.  I
forgot all about the linked list of tree entries.

> Again, probably not important, but it was interesting for me at least to
> see the evolution of the tree code. Most of those changes predate my
> involvement with the code.

Yeah, your name didn't appear in the history leading to the version
with linked list of tree entries, but by the time it was converted
to more modern "update_tree_entry()" interface, you had a handful of
commits already.

The main codepath never cared about zero-padded octal (we used to
use sscanf "%o", and these days get_mode() does it manually), but
there used to be Git implementations that zero-padded the mode
(e.g. "040000") that we need to warn about.  Both in code before and
after 15b5536ee4, we peek into the bytes directly and check '0',
independent from parsing the octal string into 'mode'.  I found that
interesting (no, there is nothing to fix, just a fun read).

Thanks.

Re: [PATCH 0/3] actually detect bad file modes in fsck

[Ævar Arnfjörð Bjarmason]

On Wed, Aug 10 2022, Jeff King wrote:

> On Wed, Aug 10, 2022 at 04:04:17PM -0400, Jeff King wrote:
>
>> > Maybe downgrade to info or ignore by default then? It might still be
>> > an issue for people who wilfully upgraded the diagnostic to error
>> > hoping to catch the, but hopefully if they did that they'd rather get
>> > the notice later than never?
>> 
>> Yeah, that may be a sensible resolution. All things being equal I think
>> "warning" is the right level, but out of caution and the historical
>> precedent, maybe downgrading it to "info" is justified.
>> 
>> It should be easy to work that into the patch I showed earlier.
>
> OK, so here are cleaned-up patches to do that.
>
>   [1/3]: tree-walk: add a mechanism for getting non-canonicalized modes
>   [2/3]: fsck: actually detect bad file modes in trees
>   [3/3]: fsck: downgrade tree badFilemode to "info"

This LGTM.

I noticed/reported this issue more than a year ago, but the series I had
for fixing it ended up being dropped, here's the report/analysis at the
time:
https://lore.kernel.org/git/20210308150650.18626-31-avarab@gmail.com/

Basically I was taking a much longer way around to avoid...

>  	/* counts the number of bytes left in the `buffer`. */
>  	unsigned int size;
> +
> +	/* option flags passed via init_tree_desc_gently() */
> +	enum tree_desc_flags {
> +		TREE_DESC_RAW_MODES = (1 << 0),
> +	} flags;
>  };

...this from 1/3 here, i.e. now we're paying the cost of an extra entry
in every "struct tree_desc" user (which includes some hot codepaths),
and just for this one fsck caller.

I wonder if we couldn't introduce a init_tree_desc_gently_flags() for
this instead. You note in 1/3 that you're (rightly) avoiding the churn
of existing callers, but they could just use a "static inline" wrapper
function that would set those flags to 0, we'd pass the flags down, and
not put them into the "tree_desc" struct.

Arguably it doesn't belong there at all, since this new thing is really
an "opts" struct, but "tree_desc" is for "the state of the walk".

It might/would make sense as a "raw_mode" in "struct name_entry"
perhaps, but then we're gettin closer to the larger scope of my initial
larger series, oh well ... :)

Re: [PATCH 0/3] actually detect bad file modes in fsck

[Jeff King]

On Thu, Aug 11, 2022 at 11:39:42AM +0200, Ævar Arnfjörð Bjarmason wrote:

> > OK, so here are cleaned-up patches to do that.
> >
> >   [1/3]: tree-walk: add a mechanism for getting non-canonicalized modes
> >   [2/3]: fsck: actually detect bad file modes in trees
> >   [3/3]: fsck: downgrade tree badFilemode to "info"
> 
> This LGTM.
> 
> I noticed/reported this issue more than a year ago, but the series I had
> for fixing it ended up being dropped, here's the report/analysis at the
> time:
> https://lore.kernel.org/git/20210308150650.18626-31-avarab@gmail.com/
> 
> Basically I was taking a much longer way around to avoid...

I took a look at that patch, but I'd really prefer _not_ to lose the
auto-canonicalizing for most code paths. It's an easy thing to forget
about, and the current state protects most code from getting confused by
malicious or buggy modes.

> >  	/* counts the number of bytes left in the `buffer`. */
> >  	unsigned int size;
> > +
> > +	/* option flags passed via init_tree_desc_gently() */
> > +	enum tree_desc_flags {
> > +		TREE_DESC_RAW_MODES = (1 << 0),
> > +	} flags;
> >  };
> 
> ...this from 1/3 here, i.e. now we're paying the cost of an extra entry
> in every "struct tree_desc" user (which includes some hot codepaths),
> and just for this one fsck caller.

Yes, but I don't think tree_desc itself is very hot. We allocate one per
iteration on the stack, not one per tree. So you'd have at most N at
once for a tree with depth N. And the rest of tree_desc is...already not
very lightweight.

In fact, I think this flag ends up in what is currently padding (I get
72 bytes for the struct before and after). Though in the long run that
"unsigned int" should almost certainly become a "size_t", which would
fill out that padding. I still doubt it's measurable.

> I wonder if we couldn't introduce a init_tree_desc_gently_flags() for
> this instead. You note in 1/3 that you're (rightly) avoiding the churn
> of existing callers, but they could just use a "static inline" wrapper
> function that would set those flags to 0, we'd pass the flags down, and
> not put them into the "tree_desc" struct.

You'd need not just that function, but wrappers for the iterator
functions. I agree it could work. It just seemed less clean to me.

> Arguably it doesn't belong there at all, since this new thing is really
> an "opts" struct, but "tree_desc" is for "the state of the walk".

I think that's a philosophical difference, and not one I really agree
with. I'd argue that options are part of the state (and we mingle them
already in other structs like rev_info).

> It might/would make sense as a "raw_mode" in "struct name_entry"
> perhaps, but then we're gettin closer to the larger scope of my initial
> larger series, oh well ... :)

Yes, I'd be OK with that approach, too. But aren't we now similarly
bloating things for a value that most callers won't care about? ;)

-Peff