{"thread":{"id":"32864","subject":"Permission denied on home dir results in fatal error as of 1.8.1.1","startedAt":"2013-02-09T00:40:19Z","lastAt":"2013-02-09T02:33:27Z","messageCount":4,"participants":["Nick Muerdter","Junio C Hamano","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209055","messageId":"CAECnihxpvtE1XejzHDCRBF=GkyBHmb53WDLa16Suiq=4SeYzvA@mail.gmail.com","threadId":"32864","inReplyTo":null,"subject":"Permission denied on home dir results in fatal error as of 1.8.1.1","fromName":"Nick Muerdter","fromEmail":"stuff@nickm.org","sentAt":"2013-02-09T00:40:19Z","receivedAt":"2013-02-09T00:40:19Z","isPatch":false,"sender":{"key":"stuff@nickm.org","avatar":null},"body":"As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home\ndirectory can't be accessed, it results in a fatal error. In git 1.8.1\nand below this same setup just resulted in warnings. Was this an\nintentional change?\n\nI ran into this in a situation where sudo is being used to execute a\nscript as root and then git ends up getting executed as a different\nuser. In this case HOME ends up being /root when git is called as this\ndifferent user. This home value is obviously incorrect, so there's an\nissue there, but it would be perhaps be nice if this still just\nresulted in warnings.\n\nHere's a simple way to reproduce if run as a non-root user:\n\ngit 1.8.1.1 (fatal error, doesn't work):\n\n$ env HOME=/root git ls-remote http://github.com/sstephenson/rbenv.git v0.4.0\nfatal: unable to access '/root/.config/git/config': Permission denied\n\ngit 1.8.1 (warnings, but still works):\n\n$ env HOME=/root git ls-remote http://github.com/sstephenson/rbenv.git v0.4.0\nwarning: unable to access '/root/.config/git/config': Permission denied\nwarning: unable to access '/root/.gitconfig': Permission denied\nwarning: unable to access '/root/.config/git/config': Permission denied\nwarning: unable to access '/root/.gitconfig': Permission denied\nwarning: unable to access '/root/.config/git/config': Permission denied\nwarning: unable to access '/root/.gitconfig': Permission denied\nwarning: unable to access '/root/.config/git/config': Permission denied\nwarning: unable to access '/root/.gitconfig': Permission denied\n9375e99f921f428849f19efe2a2e500b3295d1a7 refs/tags/v0.4.0\n\nThanks,\nNick\n"},{"id":"209057","messageId":"7v6222xqc4.fsf@alter.siamese.dyndns.org","threadId":"32864","inReplyTo":"CAECnihxpvtE1XejzHDCRBF=GkyBHmb53WDLa16Suiq=4SeYzvA@mail.gmail.com","subject":"Re: Permission denied on home dir results in fatal error as of 1.8.1.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-09T00:50:51Z","receivedAt":"2013-02-09T00:50:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Muerdter writes:\n\n> As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home\n> directory can't be accessed, it results in a fatal error. In git 1.8.1\n> and below this same setup just resulted in warnings. Was this an\n> intentional change?\n\nI think this was done to not just help diagnosing misconfiguration,\nbut to prevent an unintended misconfiguration from causing problems\n(e.g. the user thinks user.name is set up correctly, but forbids Git\nfrom reading it from the configuration files, and ends up creating\ncommits under wrong names).\n\nSomebody please correct me if this weren't the case...\n"},{"id":"209059","messageId":"20130209010534.GC8461@google.com","threadId":"32864","inReplyTo":"7v6222xqc4.fsf@alter.siamese.dyndns.org","subject":"Re: Permission denied on home dir results in fatal error as of 1.8.1.1","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-09T01:05:34Z","receivedAt":"2013-02-09T01:05:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Nick Muerdter writes:\n\n>> As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home\n>> directory can't be accessed, it results in a fatal error. In git 1.8.1\n>> and below this same setup just resulted in warnings. Was this an\n>> intentional change?\n>\n> I think this was done to not just help diagnosing misconfiguration,\n> but to prevent an unintended misconfiguration from causing problems\n> (e.g. the user thinks user.name is set up correctly, but forbids Git\n> from reading it from the configuration files, and ends up creating\n> commits under wrong names).\n\nYes, that's right. Sometimes ignoring settings has bad consequences,\nso git errors out to let the user intervene and decide whether the\ninaccessible settings are important.\n\nThanks,\nJonathan\n"},{"id":"209066","messageId":"CAECnihwGK8+cHJYQCVMtTwRnrh5V3T-v2-8dM2rd=ziRUA2x5A@mail.gmail.com","threadId":"32864","inReplyTo":"20130209010534.GC8461@google.com","subject":"Re: Permission denied on home dir results in fatal error as of 1.8.1.1","fromName":"Nick Muerdter","fromEmail":"stuff@nickm.org","sentAt":"2013-02-09T02:33:27Z","receivedAt":"2013-02-09T02:33:27Z","isPatch":false,"sender":{"key":"stuff@nickm.org","avatar":null},"body":"On Fri, Feb 8, 2013 at 6:05 PM, Jonathan Nieder wrote:\n> Junio C Hamano wrote:\n>> Nick Muerdter writes:\n>\n>>> As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home\n>>> directory can't be accessed, it results in a fatal error. In git 1.8.1\n>>> and below this same setup just resulted in warnings. Was this an\n>>> intentional change?\n>>\n>> I think this was done to not just help diagnosing misconfiguration,\n>> but to prevent an unintended misconfiguration from causing problems\n>> (e.g. the user thinks user.name is set up correctly, but forbids Git\n>> from reading it from the configuration files, and ends up creating\n>> commits under wrong names).\n>\n> Yes, that's right. Sometimes ignoring settings has bad consequences,\n> so git errors out to let the user intervene and decide whether the\n> inaccessible settings are important.\n\nThanks for the quick response.\n\nJust for reference, the specific issue I ran into stems from using\nChef to provision servers. Chef gets run as root but can perform the\ngit commands as a different user on the system. The way this appears\nto be implemented is to fork, set the uid, and then execute git. But\nsince the HOME environment variable is still set to /root, this leads\nto this fatal error. This can obviously be fixed on the script's end\nby properly determining and setting the HOME before executing git, but\nmore care has to be taken, and I'm not sure how common this fork + set\nuid + exec approach in other programs might be. But I'll file a bug\nwith Chef to get it fixed there.\n\nThanks again,\nNick\n"}]}