Re: Permission denied on home dir results in fatal error as of 1.8.1.1

[Nick Muerdter <stuff@nickm.org>]

On Fri, Feb 8, 2013 at 6:05 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Junio C Hamano wrote:
>> Nick Muerdter <stuff@nickm.org> writes:
>
>>> As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home
>>> directory can't be accessed, it results in a fatal error. In git 1.8.1
>>> and below this same setup just resulted in warnings. Was this an
>>> intentional change?
>>
>> I think this was done to not just help diagnosing misconfiguration,
>> but to prevent an unintended misconfiguration from causing problems
>> (e.g. the user thinks user.name is set up correctly, but forbids Git
>> from reading it from the configuration files, and ends up creating
>> commits under wrong names).
>
> Yes, that's right.  Sometimes ignoring settings has bad consequences,
> so git errors out to let the user intervene and decide whether the
> inaccessible settings are important.

Thanks for the quick response.

Just for reference, the specific issue I ran into stems from using
Chef to provision servers. Chef gets run as root but can perform the
git commands as a different user on the system. The way this appears
to be implemented is to fork, set the uid, and then execute git. But
since the HOME environment variable is still set to /root, this leads
to this fatal error. This can obviously be fixed on the script's end
by properly determining and setting the HOME before executing git, but
more care has to be taken, and I'm not sure how common this fork + set
uid + exec approach in other programs might be. But I'll file a bug
with Chef to get it fixed there.

Thanks again,
Nick