From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: "Michal Suchánek" <msuchanek@suse.de>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"David C. Rankin" <drankinatty@gmail.com>,
git@vger.kernel.org
Subject: Re: Local git server can't serve https until repos owned by http, can't serve ssh unless repos owned by user after 2.45.1
Date: Wed, 26 Jun 2024 11:14:39 -0700 [thread overview]
Message-ID: <xmqq34oz1shc.fsf@gitster.g> (raw)
In-Reply-To: <834862fd-b579-438a-b9b3-5246bf27ce8a@gmail.com> (Phillip Wood's message of "Wed, 26 Jun 2024 14:03:33 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
> ... What is happening is that
> git-daemon checks that the repository path is listed as safe and then
> changes into that directory and forks
>
> git upload-pack --strict .
>
> "git upload-pack" then checks "." against the list of safe directories
> which fails. It fails because the safe directory check does not do any
> normalization such as cleaning up "//" elements (as seen in your
> example) or expanding relative paths on $git_dir before checking it
> against the list of safe directories.
> ...
> I think the fix is probably to make the safe directory check use the
> absolute path of $git_dir. In the mean time there is a workaround if
> you're happy to add "." to the list of safe directories.
It still is curious why unnormalized "." does not pass "*" (which is
not even a pattern matching, but is a declaration that says "don't
bother which path we are talking about"), though. As long as the
value of that configuration is found to be '*' literally, safe
directory data is marked as "is_safe" (cf. setup.c:safe_directory_cb
and setup.c:ensure_valid_ownership; notice that data.path is not
even consulted if the value of the configuration variable is '*').
Anyway, thanks for digging.
next prev parent reply other threads:[~2024-06-26 18:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 0:36 Local git server can't serve https until repos owned by http, can't serve ssh unless repos owned by user after 2.45.1 David C. Rankin
2024-06-17 18:47 ` Junio C Hamano
2024-06-17 21:15 ` Michal Suchánek
2024-06-25 7:24 ` Michal Suchánek
2024-06-25 16:12 ` Junio C Hamano
2024-06-25 18:34 ` Michal Suchánek
2024-06-26 13:03 ` Phillip Wood
2024-06-26 18:14 ` Junio C Hamano [this message]
2024-06-26 18:35 ` Phillip Wood
2024-06-26 18:51 ` Junio C Hamano
2024-09-25 11:34 ` Michal Suchánek
2024-08-29 20:34 ` Joey Hess
2024-07-26 0:38 ` Jamie Landeg-Jones
2024-07-26 5:58 ` David C. Rankin
2024-07-28 3:46 ` Jamie Landeg-Jones
2024-07-28 6:57 ` David C. Rankin
2024-08-01 0:15 ` [SOLVED] " Jamie Landeg-Jones
2024-08-02 19:31 ` Junio C Hamano
2024-06-18 1:08 ` David C. Rankin
2024-06-24 14:53 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq34oz1shc.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=drankinatty@gmail.com \
--cc=git@vger.kernel.org \
--cc=msuchanek@suse.de \
--cc=phillip.wood123@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.