git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Justin Steven <justin@justinsteven.com>
Cc: Glen Choo <chooglen@google.com>,
	git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
	Taylor Blau <me@ttaylorr.com>
Subject: Re: Bare repositories in the working tree are a security risk
Date: Thu, 7 Apr 2022 22:10:00 +0000	[thread overview]
Message-ID: <Yk9hONuCIVIq6ieV@camp.crustytoothpaste.net> (raw)
In-Reply-To: <CAHZU0ySHqc7f9qB0+ZrMWHHJiWsS-_hsUzomwNrGNMTF6qwcOw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On 2022-04-07 at 21:53:26, Justin Steven wrote:
> Hi all,
> 
> I'm the author of one of the articles linked in Glen's mail. Thank you
> Glen for summarising the problem beautifully and pushing this forward.
> 
> Brian said:
> > As mentioned elsewhere, git status doesn't work without a working tree.
> 
> This is correct. However, it is possible to embed a bare repo that has
> its own core.worktree which points to a directory within the
> containing repo, satisfying the requirement of having a working tree.
> This is covered in the article [1] and looks to be accounted for in
> Taylor's reproducer script which admittedly I haven't run.
> 
> > Instead, I'd rather see us avoid executing any program from the config
> > or any hooks in a bare repository without a working tree (except for
> > pushes).  I think that would avoid breaking things while still improving
> > security.
> 
> Due to the fact that the embedded bare repo can be made to have a
> working tree, this won't be an effective fix.

Then we'd probably be better off just walking up the entire hierarchy
and excluding worktrees from embedded bare repositories, or otherwise
restricting the config we read.  That will probably mean we'll need to
walk the entire directory hierarchy to see if it's embedded (or at least
to the root of the device) in such a case, but that should be relatively
uncommon.

I'd definitely like to see us make a security improvement here, but I
also would like to avoid us breaking a lot of repositories, especially
since we lack alternatives.

If git fast-import could 100% correctly round-trip all commits and
repositories, I would be much more open to blocking this in fsck after a
deprecation period, but as it stands that's not possible.  Perhaps
improving that would be a suitable way forward.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2022-04-07 22:10 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 22:43 Glen Choo
2022-04-06 23:22 ` [PATCH] fsck: detect bare repos in trees and warn Glen Choo
2022-04-07 12:42   ` Johannes Schindelin
2022-04-07 13:21     ` Derrick Stolee
2022-04-07 14:14       ` Ævar Arnfjörð Bjarmason
2022-04-14 20:02         ` Glen Choo
2022-04-15 12:46           ` Ævar Arnfjörð Bjarmason
2022-04-07 15:11       ` Junio C Hamano
2022-04-13 22:24       ` Glen Choo
2022-04-07 13:12   ` Ævar Arnfjörð Bjarmason
2022-04-07 15:20   ` Junio C Hamano
2022-04-07 18:38 ` Bare repositories in the working tree are a security risk John Cai
2022-04-07 21:24 ` brian m. carlson
2022-04-07 21:53   ` Justin Steven
2022-04-07 22:10     ` brian m. carlson [this message]
2022-04-07 22:40       ` rsbecker
2022-04-08  5:54       ` Junio C Hamano
2022-04-14  0:03         ` Junio C Hamano
2022-04-14  0:04         ` Glen Choo
2022-04-13 23:44       ` Glen Choo
2022-04-13 20:37 ` Glen Choo
2022-04-13 23:36   ` Junio C Hamano
2022-04-14 16:41     ` Glen Choo
2022-04-14 17:35       ` Junio C Hamano
2022-04-14 18:19         ` Junio C Hamano
2022-04-15 21:33         ` Glen Choo
2022-04-15 22:17           ` Junio C Hamano
2022-04-16  0:52             ` Taylor Blau
2022-04-15 22:43           ` Glen Choo
2022-04-15 20:13       ` Junio C Hamano
2022-04-15 23:45         ` Glen Choo
2022-04-15 23:59           ` Glen Choo
2022-04-16  1:00           ` Taylor Blau
2022-04-16  1:18             ` Junio C Hamano
2022-04-16  1:30               ` Taylor Blau
2022-04-16  0:34 ` Glen Choo
2022-04-16  0:41 ` Glen Choo
2022-04-16  1:28   ` Taylor Blau
2022-04-21 18:25     ` Emily Shaffer
2022-04-21 18:29       ` Emily Shaffer
2022-04-21 18:47         ` Junio C Hamano
2022-04-21 18:54           ` Taylor Blau
2022-04-21 19:09       ` Taylor Blau
2022-04-21 21:01         ` Emily Shaffer
2022-04-21 21:22           ` Taylor Blau
2022-04-29 23:57     ` Glen Choo
2022-04-30  1:14       ` Taylor Blau
2022-05-02 19:39         ` Glen Choo
2022-05-02 14:05       ` Philip Oakley
2022-05-02 18:50         ` 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=Yk9hONuCIVIq6ieV@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=chooglen@google.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=justin@justinsteven.com \
    --cc=me@ttaylorr.com \
    --subject='Re: Bare repositories in the working tree are a security risk' \
    /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

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