Re: Bug: git config does not respect read-only .gitconfig file

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 9, 2016, 01:22 UTC
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.