Re: [RFC/PATCH] config: honor file permission bits

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 23, 2026, 14:54 UTC
Message-ID: <xmqq8q3obh7u.fsf@gitster.g>
In-Reply-To: <atsZX6exgGJkNQQQ@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 5 quoted lines

> 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?

The $HOME/.gitconfig file and its XDG counterparts are the only out-of-tree files that suffer from this issue, and being outside the repository is what makes them special. Theoretically, /etc/gitconfig on a multi-user system could have the same issue, but the containing directory would typically be read-only for regular users, which makes the issue irrelevant there.

I do not see any sensible reason why a user would want to "protect" in-tree files like .git/index from Git, either by running "chmod -w" on them or by any other means. We make files under the .git/objects/ hierarchy read-only, but that is to prevent accidental overwriting by tools other than Git, so it does not serve as an example of Git needing to respect read-only bits in the general lockfile machinery.

Having said all that, the patch was intentionally isolated to the caller's side of the API, primarily because auditing all code paths that use the lockfile API was far beyond my available time budget.