git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Ondrej Pohorelsky <opohorel@redhat.com>,
	 Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: git-daemon doesn't work as expected in v2.45.1 and friends
Date: Tue, 21 May 2024 08:20:10 -0700	[thread overview]
Message-ID: <xmqq5xv7chud.fsf@gitster.g> (raw)
In-Reply-To: <20240521-evasive-mindful-stoat-c58b31@meerkat> (Konstantin Ryabitsev's message of "Tue, 21 May 2024 09:27:03 -0400")

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

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


  reply	other threads:[~2024-05-21 15:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-20  8:21 git-daemon doesn't work as expected in v2.45.1 and friends Ondrej Pohorelsky
2024-05-21 13:27 ` Konstantin Ryabitsev
2024-05-21 15:20   ` Junio C Hamano [this message]
2024-05-21 20:40     ` 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=xmqq5xv7chud.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=opohorel@redhat.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 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 NNTP newsgroup(s).