git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, vdye@github.com, jonathantanmy@google.com
Subject: Re: [PATCH 1/2] pack-bitmap: check preferred pack validity when opening MIDX bitmap
Date: Fri, 13 May 2022 11:19:05 -0700	[thread overview]
Message-ID: <xmqqpmkh9tye.fsf@gitster.g> (raw)
In-Reply-To: <06eca1fba9d2597906ec342c51ba2bb5c4fde0e4.1652458395.git.me@ttaylorr.com> (Taylor Blau's message of "Fri, 13 May 2022 12:23:17 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> The pack bitmap code does this, too, since prior to bab919bd44
> (pack-bitmap: check pack validity when opening bitmap, 2015-03-26) it
> was vulnerable to the same race.

That might be a GitHub internal reference to some other commit?
dc1daacd (pack-bitmap: check pack validity when opening bitmap,
2021-07-23) is what I found.

> The MIDX bitmap code does not do this, and is vulnerable to the same
> race. Apply the same treatment as bab919bd44 to the routine responsible
> for opening multi-pack bitmaps to close this race.

Same reference here and ...

> Similar to bab919bd44, we could technically just add this check in

... here.  But the solution in dc1daacd is quite different from what
we see here in the posted patch, so perhaps you are referring to
something different.  I dunno.

The call graph around the functions involved is

  prepare_midx_bitmap_git()
   -> open_midx_bitmap_1()
      * opens, mmaps and closes bitmap file
      -> load_midx_revindex()
   -> load_bitmap()
      -> load_reverse_index()
         -> prepare_midx_pack()
         -> load_pack_revindex()

And prepare_midx_pack() for these packs is moved from
load_reverse_index() to open_midx_bitmap_1() in this patch.

In addition, after doing so, we call is_pack_valid() on the single
preferred pack and return failure.

Because load_bitmap() or load_reverse_index() cannot be done before
you do open_midx_bitmap_1(), calling prepare_midx_pack() early will
end up calling add_packed_git() on underlying packs, allowing us to
access them even when somebody else removed them from the disk?  Is
that the idea?

> reuse_partial_packfile_from_bitmap(), since it's technically possible to
> use a MIDX .bitmap without needing to open any of its packs. But it's
> simpler to do the check as early as possible, covering all direct uses
> of the preferred pack. Note that doing this check early requires us to
> call prepare_midx_pack() early, too, so move the relevant part of that
> loop from load_reverse_index() into open_midx_bitmap_1().

OK.  That matches my observation above, I guess.  I do not quite get
why it is sufficient to check only the preferred one, though.

> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> ---
>  pack-bitmap.c | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index 97909d48da..6b1a43d99c 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -315,6 +315,8 @@ static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
>  	struct stat st;
>  	char *idx_name = midx_bitmap_filename(midx);
>  	int fd = git_open(idx_name);
> +	uint32_t i;
> +	struct packed_git *preferred;
>  
>  	free(idx_name);
>  
> @@ -353,6 +355,21 @@ static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
>  		warning(_("multi-pack bitmap is missing required reverse index"));
>  		goto cleanup;
>  	}
> +
> +	for (i = 0; i < bitmap_git->midx->num_packs; i++) {
> +		if (prepare_midx_pack(the_repository, bitmap_git->midx, i))
> +			die(_("could not open pack %s"),
> +			    bitmap_git->midx->pack_names[i]);
> +	}
> +
> +	preferred = bitmap_git->midx->packs[midx_preferred_pack(bitmap_git)];
> +	if (!is_pack_valid(preferred)) {
> +		close(fd);

This close() does not look correct.  After calling xmmap() to map
the bitmap file to bitmap_git->map, we do not need the underlying
file descriptor in order to use the contents of the file.  We have
closed it already at this point.

> +		warning(_("preferred pack (%s) is invalid"),
> +			preferred->pack_name);
> +		goto cleanup;
> +	}
> +
>  	return 0;
>  
>  cleanup:
> @@ -429,8 +446,6 @@ static int load_reverse_index(struct bitmap_index *bitmap_git)
>  		 * since we will need to make use of them in pack-objects.
>  		 */
>  		for (i = 0; i < bitmap_git->midx->num_packs; i++) {
> -			if (prepare_midx_pack(the_repository, bitmap_git->midx, i))
> -				die(_("load_reverse_index: could not open pack"));
>  			ret = load_pack_revindex(bitmap_git->midx->packs[i]);
>  			if (ret)
>  				return ret;

  reply	other threads:[~2022-05-13 18:19 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 16:23 [PATCH 0/2] pack-objects: fix a pair of MIDX bitmap-related races Taylor Blau
2022-05-13 16:23 ` [PATCH 1/2] pack-bitmap: check preferred pack validity when opening MIDX bitmap Taylor Blau
2022-05-13 18:19   ` Junio C Hamano [this message]
2022-05-13 19:55     ` Taylor Blau
2022-05-13 16:23 ` [PATCH 2/2] builtin/pack-objects.c: ensure pack validity from MIDX bitmap objects Taylor Blau
2022-05-13 23:06   ` Jonathan Tan
2022-05-14 13:17     ` Taylor Blau
2022-05-16  6:07       ` Jonathan Tan
2022-05-14 13:34     ` Taylor Blau
2022-05-16  6:11       ` Jonathan Tan
2022-05-24 18:54 ` [PATCH v2 0/4] pack-objects: fix a pair of MIDX bitmap-related races Taylor Blau
2022-05-24 18:54   ` [PATCH v2 1/4] pack-bitmap.c: check preferred pack validity when opening MIDX bitmap Taylor Blau
2022-05-24 19:36     ` Ævar Arnfjörð Bjarmason
2022-05-24 21:38       ` Taylor Blau
2022-05-24 21:51         ` Ævar Arnfjörð Bjarmason
2022-05-24 18:54   ` [PATCH v2 2/4] builtin/pack-objects.c: avoid redundant NULL check Taylor Blau
2022-05-24 21:44     ` Junio C Hamano
2022-05-25  0:11       ` Taylor Blau
2022-05-24 18:54   ` [PATCH v2 3/4] builtin/pack-objects.c: ensure included `--stdin-packs` exist Taylor Blau
2022-05-24 19:46     ` Ævar Arnfjörð Bjarmason
2022-05-24 21:33       ` Taylor Blau
2022-05-24 21:49         ` Ævar Arnfjörð Bjarmason
2022-05-24 22:03     ` Junio C Hamano
2022-05-25  0:14       ` Taylor Blau
2022-05-26 19:21     ` Victoria Dye
2022-05-26 20:05       ` Taylor Blau
2022-05-24 18:54   ` [PATCH v2 4/4] builtin/pack-objects.c: ensure pack validity from MIDX bitmap objects Taylor Blau
2022-05-24 21:38   ` [PATCH v2 0/4] pack-objects: fix a pair of MIDX bitmap-related races Junio C Hamano
2022-05-25  0:16     ` Taylor Blau

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

  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 \
    --in-reply-to=xmqqpmkh9tye.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=me@ttaylorr.com \
    --cc=vdye@github.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).