Git development
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] config: honor file permission bits
Date: Fri, 23 Oct 2026 10:23:05 +0200	[thread overview]
Message-ID: <atsZX6exgGJkNQQQ@pks.im> (raw)
In-Reply-To: <xmqqbj8p7okv.fsf@gitster.g>

On Mon, Oct 19, 2026 at 07:27:28AM -0700, Junio C Hamano wrote:
> Because our updates to an existing file almost never makes
> modifications in place, and instead create a new "lockfile",
> propagate the permission bits from the original, copy the contents
> from the original file while tweaking the contents as needed, and
> then finally rename the lockfile to replace the original file, you
> cannot "protect" your .global configuration file from accidental
> clobbering by doing something like this:
> 
> 	$ chmod a-w $HOME/.gitconfig
> 
> Of course, if you make your $HOME directory unwritable, it may
> protect your .gitconfig from getting updated, but that goes totally
> against the intuition and is not how you would protect a regular
> file from getting overwritten.
> 
> Teach the configuration file writing machinery to inspect the
> permission bits of the original with access(2) and refrain from
> doing the usual "write a lockfile and replace the original with it"
> dance ourselves when we shouldn't be able to write it.

What I wonder is what makes our config file so special compared to
everything else that uses lockfiles. Or put differently: if we think
it's important to honor permissions bits (which I think is sensible),
shouldn't we do that in a central location like in "lockfile.c" so that
all users of this interface behave the same?

Patrick

  parent reply	other threads:[~2026-10-23  8:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 14:27 [RFC/PATCH] config: honor file permission bits Junio C Hamano
2026-10-22 20:59 ` Junio C Hamano
2026-10-22 21:08   ` brian m. carlson
2026-10-22 23:29     ` Junio C Hamano
2026-10-23  8:23 ` Patrick Steinhardt [this message]
2026-10-23 14:54   ` Junio C Hamano
2026-10-26  8:40     ` Patrick Steinhardt
2026-10-26 15:01       ` Junio C Hamano
2026-10-26 14:59 ` [PATCH v2] " 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=atsZX6exgGJkNQQQ@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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