From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 09 Nov 2016 01:22:52 GMT
Subject: Re: Bug: git config does not respect read-only .gitconfig file
Message-ID: <xmqqk2cdbg5v.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20161108200110.zvqdm2nlu5zxfyv5@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Probably converting "rename(from, to)" to first check "access(to,
> W_OK)". That's racy, but it's the best we could do.

Hmph, if these (possibly problematic) callers are all following the
usual "lock, write to temp, rename" pattern, perhaps the lock_file()
function can have access(path, W_OK) check before it returns a
tempfile that has been successfully opened?

Having said that, I share your assessment that this is not a code or
design problem.  It is unreasonable to drop the write-enable bit of
a file in a writable directory and expect it to stay unmodified. The
W-bit on the file is not usable as a security measure, and we do not
use it as such.

I do not offhand know how much a new feature "this repository can be
modified by pushing into and fetching from, but its configuration
cannot be modified" is a sensible thing to have.  But it is quite
clear that even if we were to implement such feature, we wouldn't be
using W-bit on .git/config to signal that.