Re: git-daemon doesn't work as expected in v2.45.1 and friends

From: Junio C Hamano <gitster@pobox.com>
Date: May 21, 2024, 15:20 UTC
Message-ID: <xmqq5xv7chud.fsf@gitster.g>
In-Reply-To: <20240521-evasive-mindful-stoat-c58b31@meerkat>

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

Show 9 quoted lines

> On Mon, May 20, 2024 at 10:21:23AM GMT, Ondrej Pohorelsky wrote:
>> Is there a way to make git-daemon hosted repositories safe to clone,
>> without specifying safe.directory in git config? AFAIK this is widely
>> used feature of Git not only by the end users, but also quite a lot of
>> tests rely on it.
>
> I would say more -- this is very broken and needs to be rolled back. Running
> git-daemon as a different user is the recommended setup for read-only
> deployments.

Is this from f4aa8c8b (fetch/clone: detect dubious ownership of local repositories, 2024-04-10) where the commit sprinkled a "protection" meant only for "local clone" to more generic code paths that are also used by "git daemon" serving a remote clients? It may be that the commit was a bit too aggressive and had a blast radius that is much larger than intended?

I think that 1204e1a8 (builtin/clone: refuse local clones of unsafe repositories, 2024-04-15), which is a very pointed fix to ensure we do not "hardlink copy" local repository owned by others for security, was a good use of die_upon_dubious_ownership() call, though.

Reverting f4aa8c8b may not be easy to do mechanically, as it introduces the die_upon_dubious_ownership(), but 1204e1a8 uses an identical copy of the same function introduced by 8c9c051b (setup.c: introduce `die_upon_dubious_ownership()`, 2024-04-15), and reverting f4aa8c8b mechanically out of the merged result in v2.45.1 would likely to remove the function that is still in use, which would need to be retained.