Git Mailing List Archive mirror
 help / color / mirror / Atom feed

From: "J. Paul Reed" <preed@sigkill.com>
To: git@vger.kernel.org
Subject: Odd git-config behavior
Date: Mon, 31 Oct 2022 13:51:57 -0700	[thread overview]
Message-ID: <Y2A1bdiw6kGC65f/@sigkill.com> (raw)


Hey all,

I recently ran into interesting behavior with git-config (which I
originally thought was a bug).

I was converting repos from the deprecated core.fsyncObjectFiles to the new
core.fsync option suite; I wrote some automation to do that, using
"git config -l" to detect previously-converted repos.

But then some weekly repo maintenance automation complained about the
deprecated fsync option being present in some of the repo configs, even
though I thought those repos had been converted to the new settings.

I did some digging, and it turns out that "git config -l" was reporting
nothing (no output) in Git 2.37.4. I did some testing, and found that Git
2.35.1 correctly reporting the repo's config settings.

Interestingly, the maintenance automation runs fsck and some other things,
and reports the presence of the deprecated fsync setting (which is what
made me notice); so that code path does read the config and run (and
complain about the presence of deprecated settings).

I did a git bisect between 2.35.1 and 2.37.4, and it looks like the
following commit changes the behavior:

8959555cee7ec045958f9b6dd62e541affb7e7d9 is the first bad commit
commit 8959555cee7ec045958f9b6dd62e541affb7e7d9
Author: Johannes Schindelin <johannes.schindelin@gmx.de>
Date:   Wed Mar 2 12:23:04 2022 +0100

    setup_git_directory(): add an owner check for the top-level directory
    
    It poses a security risk to search for a git directory outside of the
    directories owned by the current user.

    [full commit message clipped]

So... my maintenance automation runs as root, and the repo directories are
uid/gid'd someone else (though, the config file inside the [bare] repo
happens to be owned by root)... so I suppose what I'm observing is expected
behavior?

I guess this leaves me with two questions:

    1. Why does "git config" refuse to run due to this security check, but
       other git commands ("git fsck," at least) run?

    2. I think it might be useful to warn the user that the behavior they're
       expecting isn't happening due to this security check, instead of just
       outputting objectively wrong information (i.e. that no config options
       exist when they actually do exist); I'd be curious what others think.

best,
preed
-- 
J. Paul Reed
https://jpaulreed.com
PGP: 0x41AA0EF1

next             reply	other threads:[~2022-10-31 20:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 20:51 J. Paul Reed [this message]
2022-11-04 11:47 ` Odd git-config behavior Thomas Guyot
2022-11-08 23:08   ` J. Paul Reed
2022-11-09  7:02     ` Thomas Guyot

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=Y2A1bdiw6kGC65f/@sigkill.com \
    --to=preed@sigkill.com \
    --cc=git@vger.kernel.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).