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

From: Jeff King <peff@peff.net>
Date: Nov 8, 2016, 20:01 UTC
Message-ID: <20161108200110.zvqdm2nlu5zxfyv5@sigill.intra.peff.net>
In-Reply-To: <CAD9aWCgZkuaZNMDparVZE_WNFpOp7ud6iyCueGVbnU8s_EYtrQ@mail.gmail.com>

On Tue, Nov 08, 2016 at 12:18:22PM -0500, Jonathan Word wrote:

Show 5 quoted lines

> The point of confusion to users ( / my team) is that `git config`
> gives the appearance of editing / modifying the .gitconfig file
> in-place (where file permissions would be respected) however the
> actual implementation performs the equivalent of a rm+mv which only
> respects directory permissions.

The reason for the tmpfile/rename is that git-config actually takes a dot-lock on the file while writing it. Simultaneous writers are blocked, and simultaneous readers see an atomic view of the file (either the state before or after the write, but never a half-written file). Most of git's file-writes are done this way.

Show 5 quoted lines

> The `git config` command is only one of many that leverage that
> rename_tempfile function, if opting to respect file-level permissions
> across the board then the desired change is probably at that level
> rather than in config::git_config_set_multivar_in_file_gently which
> would only add respect for file-level permissions to the one command.

I am not convinced this is a code problem and not simply a documentation issue, but if you wanted to add an option to try to respect file permissions, then yes, I agree it should be done across the board. Probably converting "rename(from, to)" to first check "access(to, W_OK)". That's racy, but it's the best we could do.

-Peff