Re: [RFC/PATCH] config: honor file permission bits
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 22, 2026, 20:59 UTC
- Message-ID
- <xmqqpkx1e9iq.fsf@gitster.g>
- In-Reply-To
- <xmqqbj8p7okv.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 25 quoted lines
> 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. > > Signed-off-by: Junio C Hamano <gitster@pobox.com> > --- > config.c | 22 ++++++++++++++++++++++ > t/t1300-config.sh | 30 ++++++++++++++++++++++++++++++ > 2 files changed, 52 insertions(+)
Hmph, no responses to this RFC. I somehow find it hard to believe that I was the only person who got annoyed by this behaviour [*].
[Footnote]
* I was very tempted to write "unexpected behaviour", but I know what happens in the code path, so it is not unexpected at least to me.