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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

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