Re: Bare repositories in the working tree are a security risk

From: Junio C Hamano <gitster@pobox.com>
To: Glen Choo <chooglen@google.com>
Cc: git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
	justin@justinsteven.com, Taylor Blau <me@ttaylorr.com>,
	martinvonz@google.com,
	"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: Bare repositories in the working tree are a security risk
Date: Thu, 14 Apr 2022 10:35:11 -0700	[thread overview]
Message-ID: <xmqqbkx31sc0.fsf@gitster.g> (raw)
In-Reply-To: <kl6lh76v8vnj.fsf@chooglen-macbookpro.roam.corp.google.com> (Glen Choo's message of "Thu, 14 Apr 2022 09:41:36 -0700")

Glen Choo <chooglen@google.com> writes:

> Yes, I mean that even the current directory will be ignored when
> discovery is disabled.

OK.

>>                                                I am not sure that
>> is realistically feasible (I am thinking of cases like "git fetch"
>> going to the remote repository on the local disk that is bare to run
>> "git upload-pack"), but if the fallout is not too bad, it may be a
>> good heuristics.
>
> Good detail - I hadn't considered the impact on our own child processes.
> I suspect this might be a huge undertaking. Unless there is significant
> interest in this option, I probably won't pursue it further.

I do not necessarily think so.  The entry points to transport on the
server side are quite limited (and the client side is dealing with
your own repositories anyway), and they already know which directory
in the server filesystem to hand to the upload-pack and friends, so
it would be a matter of passing GIT_DIR=$there when they call into the
run_command() API, if they are not already doing so.