Re: git-daemon: needs /root/.config/git/config?
From: Ian Kumlien <hidden>
Date: 2016-06-15 22:57:33
On Tue, Jun 04, 2013 at 12:08:15PM -0400, Jeff King wrote:
On Tue, Jun 04, 2013 at 04:13:14PM +0200, Ian Kumlien wrote:quoted
Due to the earlier problem I upgraded git on all machines and eneded up with a ubunut machine running in to problems. I started getting errors like: "fatal: protocol error: bad line length character: fata" Which after some head scratching caused me to tell xinetd to directly launch git-daemon, eventually it worked fine, but i did get this error message:Looks like your stderr was being redirected to your stdout; this particular error aside, that is likely to cause weird protocol problems for any error that git outputs.
Yeah =)
quoted
Jun 4 16:12:05 xyz git-daemon[10246]: unable to access '/root/.config/git/config': Permission denied It's not the first time i've seen it but i've been able to ignore it before. This is running as a local user (as in not root) and this user shouldn't have access to /root. But i eventually had to do chown o+x /root to workaround this error.The problem is that you have presumably dropped privileges in the daemon instance, but your $HOME environment variable still points to /root. Git cannot read all of its config files (nor even find out if they exist), so it bails rather than continue.
Yeah, assumed =P
Older versions of git silently ignored errors reading config files, but it was tightened in v1.8.1.1, as there can be quite serious implications to failing to read expected config (e.g., imagine transfer.fsckobjects, or receive.deny* is ignored).
Yes, i agree, it's suboptimal but I for one would use getpwuid to get the home directory of the executing user to avoid this - though i don't know how portable it is (or if there is any other issues) It's a bit hard to control this with xinetd doing it behind the scenes...
However, since changing user id and leaving $HOME is so common, there is a patch under consideration to loosen the check only for the case of EACCES on files in $HOME. That commit is 4698c8f (config: allow inaccessible configuration under $HOME, 2013-04-12); it's not yet in any released version of git, though.
Ah, ok, thanks, I'll have a look - maybe i can actually contribute something for once =)
In the meantime, the suggested workaround is to set $HOME for the git-daemon user, rather than loosening /root.
Well, I have no idea of how to control HOME in xinetd - access to the machine is limited and x doesn't give that much access (nothing really important is actually stored in /root) For now, this is the workaround we have =P
-Peff