Re: git-daemon: needs /root/.config/git/config?

From: Ian Kumlien <pomac@vapor.com>
Date: Jun 5, 2013, 11:19 UTC
Message-ID: <20130605111918.GE22308@pomac.netswarm.net>
In-Reply-To: <20130604160815.GB15953@sigill.intra.peff.net>

On Tue, Jun 04, 2013 at 12:08:15PM -0400, Jeff King wrote:

Show 15 quoted lines

> On Tue, Jun 04, 2013 at 04:13:14PM +0200, Ian Kumlien wrote:
> 
> > 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 =)

Show 12 quoted lines

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

Show 5 quoted lines

> 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