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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
> 
> > 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 =)

> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]