From: Jeff King <email@example.com>
To: "René Scharfe" <firstname.lastname@example.org>
Cc: "Git List" <email@example.com>,
"Junio C Hamano" <firstname.lastname@example.org>,
"Ævar Arnfjörð Bjarmason" <email@example.com>
Subject: Re: [PATCH] tree-walk: disallow overflowing modes
Date: Sun, 22 Jan 2023 17:02:06 -0500 [thread overview]
Message-ID: <Y82yXskkgH00vaGy@coredump.intra.peff.net> (raw)
On Sun, Jan 22, 2023 at 11:03:38AM +0100, René Scharfe wrote:
> Am 22.01.23 um 08:50 schrieb Jeff King:
> > On Sat, Jan 21, 2023 at 10:36:09AM +0100, René Scharfe wrote:
> >> When parsing tree entries, reject mode values that don't fit into an
> >> unsigned int.
> > Seems reasonable. I don't think you can cause any interesting mischief
> > here, but it's cheap to check, and finding data problems earlier rather
> > than later is always good.
> > Should it be s/unsigned int/uint16_t/, though?
> "mode" is declared as unsigned int, and I was more concerned with
> overflowing that.
Doh, I just did "vim -t get_mode" and ended up in the near-identical
version in fast-import.c, which uses uint16_t. Maybe it would want the
same treatment. ;)
> We could be more strict and reject everything that oversteps
> S_IFMT|ALLPERMS, but the latter is not defined everywhere. But
> permission bits are well-known, so the magic number 07777 should be
> recognizable enough. Like this?
It feels like this level of check should be happening in the fsck
caller. In particular, it's nice for this parsing layer to err on the
forgiving side, because the way you get out of these situations often
involves something like "git ls-tree | git mktree".
So in that sense, even pushing the overflow detection into the fsck
would be nice, but of course it's hard to do, since we have no way to
represent the overflowed value. I guess we could have a "be more
careful" flag that the fsck code would pass, but I'm not sure it's worth
the added complexity.
next prev parent reply other threads:[~2023-01-22 22:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 9:36 [PATCH] tree-walk: disallow overflowing modes René Scharfe
2023-01-22 7:50 ` Jeff King
2023-01-22 10:03 ` René Scharfe
2023-01-22 16:36 ` Junio C Hamano
2023-01-22 22:02 ` Jeff King [this message]
2023-01-23 8:33 ` Ævar Arnfjörð Bjarmason
2023-01-24 18:53 ` René Scharfe
2023-01-24 20:44 ` Junio C Hamano
2023-01-26 11:36 ` Jeff King
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).