worktree repair: avoid breaking unrelated .git file and gitdir

[yoichi]

'git worktree repair' does not sufficiently validate the cross-references
between a linked working tree and its administrative data before
repairing them. This can cause the repair to modify the wrong .git file
or gitdir in certain situations.

This series first refactors the code to read the .git file once and extract
the worktree ID, then uses that information to validate the repair target
before modifying the cross-references.

• [1/2] Refactor the code without changing functionality before making the fix
• [2/2] Validate the worktree ID and inferred gitdir path before repairing

cc: Eric Sunshine sunshine@sunshineco.com
cc: Yoichi NAKAYAMA yoichi.nakayama@gmail.com

[yoichi]

/submit

[gitgitgadget]

Submitted as pull.2225.git.1789269613.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2225/yoichi/worktree-repair-keep-unrelated-gitfile-v1

To fetch this version to local tag pr-2225/yoichi/worktree-repair-keep-unrelated-gitfile-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2225/yoichi/worktree-repair-keep-unrelated-gitfile-v1

[gitgitgadget]

Yoichi NAKAYAMA wrote on the Git mailing list (how to reply to this email):

Friendly ping on this :)

[gitgitgadget]

User Yoichi NAKAYAMA <yoichi.nakayama@gmail.com> has been added to the cc: list.

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Yoichi NAKAYAMA via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +static const char *get_worktree_id(const char *dotgit_contents)
> +{
> +	const char *slash = find_last_dir_sep(dotgit_contents);
> +	if (!slash)
> +		return "";
> +	return slash + 1;
> +}

This returns a pointer into dotgit_contents; it is the last
component of a pathname, similar to what basename(3) gives us.

> @@ -798,30 +806,20 @@ static int is_main_worktree_path(struct repository *repo, const char *path)

The unified diff is a bit hard to follow, so let's see if we can
compare preimage and postimage more easily.

>  static ssize_t infer_backlink(struct repository *repo,
> -			      const char *gitfile,
>  			      struct strbuf *inferred)
>  {
> -	struct strbuf actual = STRBUF_INIT;
>  	const char *id;
>  
> -	if (strbuf_read_file(&actual, gitfile, 0) < 0)
> -		goto error;
> -	if (!starts_with(actual.buf, "gitdir:"))
> -		goto error;
> -	if (!(id = find_last_dir_sep(actual.buf)))
> -		goto error;
> -	strbuf_trim(&actual);
> -	id++; /* advance past '/' to point at <id> */
>  	if (!*id)
>  		goto error;
>  	repo_common_path_replace(repo, inferred, "worktrees/%s", id);
>  	if (!is_directory(inferred->buf))
>  		goto error;
>  
> -	strbuf_release(&actual);
>  	return inferred->len;
>  error:
> -	strbuf_release(&actual);
>  	strbuf_reset(inferred); /* clear invalid path */
>  	return -1;

We used to receive the filename of ".git", read it and made sure we
have "gitdir:" prefix, and find the last component, but then trimmed
the actual buffer.  Which means a few things.

 - If the contents of the gitfile were "gitdir:foo/bar/baz \n", our
   id pointer found the slash after "foo/bar", trimmed the buffer to
   have "gitdir:foo/bar/baz", and then incremented id, which now
   points at "baz".

 - If the contents of the gitfile were "gitdir: foo/bar/   \n", then
   after triming, the buffer would have "gitdir: foo/bar/" and id
   would be pointing at the NUL at the end, which would have lead us
   to error.

Now let's look at the new code.

> @@ -798,30 +806,20 @@ static int is_main_worktree_path(struct repository *repo, const char *path)
>   * Returns -1 on failure and strbuf.len on success.
>   */
>  static ssize_t infer_backlink(struct repository *repo,
> +			      const char *dotgit_contents,
>  			      struct strbuf *inferred)
>  {
>  	const char *id;
>  
> +	id = get_worktree_id(dotgit_contents);
>  	if (!*id)
>  		goto error;
>  	repo_common_path_replace(repo, inferred, "worktrees/%s", id);
>  	if (!is_directory(inferred->buf))
>  		goto error;
>  
>  	return inferred->len;
>  error:
>  	strbuf_reset(inferred); /* clear invalid path */
>  	return -1;

The caller is expected to give us the contents of gitfile read by
setup.c:read_gitfile_raw(), which reads the file in full, validates
that the file begins with "gitdir: " (notice the trailing space),
removes arbitrary run of CR or LF from the end, and then returns
the string after skipping "gitdir: " prefix (8 bytes).

In the normal case, read_gitfile_raw() would see "gitdir: foo/bar/baz\n" 
in the file and returns "foo/bar/baz" to our caller.  In fishy cases
we examined for the preimage above:

 - If the contents of the gitfile were "gitdir:foo/bar/baz \n", our
   caller would have received an error from read_gitfile_raw() and
   wouldn't have called us.

 - If the contents of the gitfile were "gitdir: foo/bar/   \n", our
   caller would have given us "foo/bar/   ".

get_worktree_id() will give us "baz" in the normal case, and "   "
in the last case.  We fail to error out in the latter with "*id"
check, but is_directory() check will catch us, as the inferred
directory is "worktrees/   " in that bad case.

So there are certain differences in error cases, but they behave the
same in the most basic cases.


Now, this is the caller in the preimage (i.e., what we used to do).

> @@ -856,51 +855,49 @@ void repair_worktree_at_path(struct repository *repo,
>  		goto done;
>  	}
>  
> -	infer_backlink(repo, dotgit.buf, &inferred_backlink);
> -	strbuf_realpath_forgiving(&inferred_backlink, inferred_backlink.buf, 0);
> -	dotgit_contents = xstrdup_or_null(read_gitfile_gently(dotgit.buf, &err));

We used to have infer_backlink() read the .git file to compute "worktree/$id",
then again called read_gitfile_gently() to read it again.

> -	if (dotgit_contents) {
> -		strbuf_addstr(&backlink, dotgit_contents);

This is the happy path.  We successfully read from .git and use it.

> -	} else if (err == READ_GITFILE_ERR_NOT_A_FILE ||
> -			err == READ_GITFILE_ERR_IS_A_DIR) {
>  		fn(1, dotgit.buf, _("unable to locate repository; .git is not a file"), cb_data);
>  		goto done;

This is inherited badness, but overly long lines like this one needs
to be fixed.

> -	} else if (err == READ_GITFILE_ERR_NOT_A_REPO) {

The _gently() did read something, but that does not point at a git
directory.

> -		if (inferred_backlink.len) {
> -			/*
> -			 * Worktree's .git file does not point at a repository
> -			 * but we found a .git/worktrees/<id> in this
> -			 * repository with the same <id> as recorded in the
> -			 * worktree's .git file so make the worktree point at
> -			 * the discovered .git/worktrees/<id>.
> -			 */
> -			strbuf_swap(&backlink, &inferred_backlink);

If we had the "worktree/$id" thing, we use it.

> -		} else {
> -			fn(1, dotgit.buf, _("unable to locate repository; .git file does not reference a repository"), cb_data);
> -			goto done;
> -		}
> -	} else {
>  		fn(1, dotgit.buf, _("unable to locate repository; .git file broken"), cb_data);
>  		goto done;
>  	}

These lines to show error messages should also be folded to avoid
overly long lines.

So, what does the updated code in the postimage do?

> @@ -856,51 +855,49 @@ void repair_worktree_at_path(struct repository *repo,
>  		goto done;
>  	}
>  
> +	err = read_gitfile_raw(&contents, dotgit.buf);

We use read_gitfile_raw() just once.

> +	if (err == READ_GITFILE_ERR_NOT_A_FILE ||
> +	    err == READ_GITFILE_ERR_IS_A_DIR) {
>  		fn(1, dotgit.buf, _("unable to locate repository; .git is not a file"), cb_data);
>  		goto done;
> +	} else if (err) {
>  		fn(1, dotgit.buf, _("unable to locate repository; .git file broken"), cb_data);
>  		goto done;
>  	}

The original code handled the happy case that read_gitfile_gently()
successfully returned first.  Underlying read_gitfile_raw() would
not have given any of these errors when read_gitfile_gently()
succeeded, so handling the error cases first would not affect the
behaviour of the code in these cases.  Again, these overlong lines
are annoying.

Now the simplest error cases are behind us.  How would we do in the
happy case?

> +	dotgit_contents = contents.buf;
> +	infer_backlink(repo, dotgit_contents, &inferred_backlink);
> +	strbuf_realpath_forgiving(&inferred_backlink, inferred_backlink.buf, 0);

We reuse what we already read with read_gitfile_raw(), which
prepared "worktrees/$id", and do the same realpath_forgiving()
the original used to do a bit earlier.

> +	if (is_absolute_path(dotgit_contents)) {
> +		strbuf_addstr(&backlink, dotgit_contents);

I am not sure which part of the original this logic corresponds to.
If the result from read_gitfile_raw() is an absolute path, even if
it later turns out not to be is_git_directory(), the inferred backlink
is not given a chance to act as a fallback.  The original made a
call to read_gitfile_gently() which checked is_git_directory() to
give us an error, and that is how it allowed inferred backlink to
substitute for a bad contents stored in .git file.  Now we do not
allow that fallback if .git file has an absolute path?

Ah, outside the context of this patch, before we barf for "unable to
locate repository" when we complain backlink.buf is not naming a git
directory, there is the fallback logic, and in order to reach there,
we have "if (!is_git_directory(backlink.buf) && !inferred_backlink.len)"
there.  OK, so this may be doing the same thing as the original, but
it is rather hard to follow and convince readers that this is a
no-op conversion.

> +	} else {
> +		strbuf_addbuf(&backlink, &dotgit);
> +		strbuf_strip_suffix(&backlink, ".git");
> +		strbuf_addstr(&backlink, dotgit_contents);
> +		strbuf_realpath_forgiving(&backlink, backlink.buf, 0);

This converts dotgit_contents relative to the computed backlink,
which needs to be done here because read_gitfile_gently() used to do
that for us, which we no longer use.

> +	}
> +
> +	if (!is_git_directory(backlink.buf) && !inferred_backlink.len) {
> +		fn(1, dotgit.buf, _("unable to locate repository; .git file does not reference a repository"), cb_data);
> +		goto done;
> +	}

I'll stop here.