git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Kevin Locke <kevin@kevinlocke.name>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] setup: don't die if realpath(3) fails on getcwd(3)
Date: Fri, 20 May 2022 17:14:41 -0700	[thread overview]
Message-ID: <CABPp-BH+=zd_ZpPMy=S5Q-ygTW85ZXD9-RLOk9Apt_Q1_SgzzA@mail.gmail.com> (raw)
In-Reply-To: <80eeba2b2a58af2a5497f398beb5c03447c41f61.1653003552.git.kevin@kevinlocke.name>

Hi,

Thanks for sending along a fix!

On Thu, May 19, 2022 at 4:39 PM Kevin Locke <kevin@kevinlocke.name> wrote:
>
> Prior to Git 2.35.0, git could be run from an inaccessible working
> directory so long as the git repository specified by options and/or
> environment variables was accessible.  For example:

Ah, good point.

>     git init repo
>     mkdir -p a/b
>     cd a/b
>     chmod u-x ..
>     git -C "${PWD%/a/b}/repo" status
>
> If this example seems a bit contrived, consider running with the
> repository owner as a substitute UID (e.g. with runuser(1) or sudo(8))
> without ensuring the working directory is accessible by that user.
>
> The code added by e6f8861bd4 to preserve the working directory attempts

When referencing commits in commit messages, this project prefers that the first
reference in the commit message use the output from `git log --no-walk
--pretty=reference $HASH` rather than just $HASH.
So, here, it'd be

    The code added by e6f8861bd4 (setup: introduce
startup_info->original_cwd, 2021-12-09) to preserve the ...

> to normalize the path using strbuf_realpath().  If that fails, as in the
> case above, it is treated as a fatal error.  To avoid this, we can
> continue after the error.  At worst, git will fail to detect that the
> working directory is inside the worktree, resulting in the pre-2.35.0
> behavior of not preserving the working directory.
>
> Fixes: e6f8861bd4 ("setup: introduce startup_info->original_cwd")

I was slightly surprised to see this tag, but it appears others in
git.git have used it, so it must just be me that's not familiar with
it.

> Signed-off-by: Kevin Locke <kevin@kevinlocke.name>

Nicely explained commit message.

> ---
>  setup.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index a7b36f3ffb..fb68caaae0 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -458,11 +458,13 @@ static void setup_original_cwd(void)
>          *     not startup_info->original_cwd.
>          */
>
> -       /* Normalize the directory */
> -       strbuf_realpath(&tmp, tmp_original_cwd, 1);
> -       free((char*)tmp_original_cwd);
> +       /* Try to normalize the directory.  Fails if ancestor not readable. */

Is that the only reason it fails?  I'm unsure if the second half of
the comment helps there.

> +       if (strbuf_realpath(&tmp, tmp_original_cwd, 0)) {
> +               free((char*)tmp_original_cwd);
> +               startup_info->original_cwd = strbuf_detach(&tmp, NULL);
> +       } else

git.git coding style: if either of the if/else blocks use braces, use
braces for both

> +               startup_info->original_cwd = tmp_original_cwd;

tmp_original_cwd is not required to be normalized, and there are very
strong normalization assumptions on startup_info->original_cwd.  While
a non-normalized value would work to get pre-2.35.0 behavior, it's by
accident rather than design, and might be confusing for others to
later reason about.  Also, I think it might be possible for
tmp_original_cwd to still be NULL, and some of the immediately
following code I believe will assume it's operating with a non-NULL
value, so you'd need to skip that stuff.  I think the else block here
should use "goto no_prevention_needed", as the no_prevention_needed
block will handle setting startup_info->original_cwd to NULL for you,
and get you the pre-2.35.0 behavior.

>         tmp_original_cwd = NULL;

After changing the above else block to a goto, you may also want to
copy this to the no_prevention_needed block or else copy it to the
else portion of the block above (just before the goto you add).

> -       startup_info->original_cwd = strbuf_detach(&tmp, NULL);
>
>         /*
>          * Get our worktree; we only protect the current working directory
> --
> 2.35.1

Again, thanks for sending in a bug fix!  Looking forward to seeing
your revised patch.

  parent reply	other threads:[~2022-05-21  0:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19 23:39 [PATCH] setup: don't die if realpath(3) fails on getcwd(3) Kevin Locke
2022-05-20 18:38 ` Junio C Hamano
2022-05-21  0:14 ` Elijah Newren [this message]
2022-05-21 13:02   ` Kevin Locke
2022-05-23 18:44     ` Derrick Stolee
2022-05-21 13:53 ` [PATCH v2] " Kevin Locke
2022-05-23 18:57   ` Derrick Stolee
2022-05-24 14:02     ` Kevin Locke
2022-05-24 15:20       ` Elijah Newren
2022-05-24 17:38         ` Derrick Stolee
2022-05-25  3:47           ` Elijah Newren
2022-05-27  7:48         ` Ævar Arnfjörð Bjarmason
2022-05-28  1:27           ` Elijah Newren
2022-05-24 14:51   ` [PATCH v3] " Kevin Locke
2022-05-24 15:21     ` Elijah Newren
2022-05-24 17:41     ` Derrick Stolee
2022-05-24 18:00       ` Kevin Locke
2022-05-24 19:20     ` [PATCH v4] " Kevin Locke
2022-05-24 20:40       ` Derrick Stolee
2022-05-24 21:25       ` Junio C Hamano
2022-05-25  3:51         ` Elijah Newren
2022-05-25  5:11           ` Junio C Hamano

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='CABPp-BH+=zd_ZpPMy=S5Q-ygTW85ZXD9-RLOk9Apt_Q1_SgzzA@mail.gmail.com' \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kevin@kevinlocke.name \
    /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).