Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 460370 - >=dev-vcs/git-1.8.1.1 unable to access '/root/.config/git/config': Permission denied
Summary: >=dev-vcs/git-1.8.1.1 unable to access '/root/.config/git/config': Permission...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Robin Johnson
URL: http://git.661346.n2.nabble.com/Permi...
Whiteboard:
Keywords: PATCH
: 468512 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-05 04:58 UTC by Manuel Rüger (RETIRED)
Modified: 2014-02-08 15:41 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
git-daemon-initd.patch (file_460370.txt,757 bytes, text/plain)
2013-03-05 21:29 UTC, Manuel Rüger (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Rüger (RETIRED) gentoo-dev 2013-03-05 04:58:30 UTC
First I'm not sure if this is a misconfiguration by myself.


I run gitolite-3.3 on my server providing an overlay I access with layman. 

With <git-1.8.1.1 everything works fine. After upgrade on git-1.8.1.1 or later, I receive on local side:

 * 
 * Errors:
 * ------
 * Failed to sync overlay "myoverlay".
 * Error was: Syncing overlay "myoverlay" returned status 1!
 * db.sync()
 * 


Remote side writes to /var/log/daemon.log

Mar  5 05:11:51 foo git-daemon[22720]: Connection from 78.53.40.255:53462
Mar  5 05:11:52 foo git-daemon[22720]: Extended attributes (14 bytes) exist <host=rueg.eu>
Mar  5 05:11:52 foo git-daemon[22720]: Request upload-pack for '/myoverlay.git'
Mar  5 05:11:52 foo git-daemon[22720]: unable to access '/root/.config/git/config': Permission denied
Mar  5 05:11:52 foo git-daemon[22397]: [22720] Disconnected (with error)

Remote side settings in /etc/conf.d/git-daemon

GITDAEMON_OPTS="--reuseaddr --syslog --verbose --export-all --base-path=/var/lib/gitolite/repositories -- /var/lib/gitolite/repositories"
GIT_USER="git"
GIT_GROUP="git"


Pulling/Pushing as a normal user works fine, just getting the overlay via layman doesn't work anymore. 

As the remote side says "/root/.config/git/config" is missing maybe $HOME doesn't get overwritten correctly, when running git-daemon via the init-script (see $URL).

ps  output:
root     28300  0.0  0.0  12692  1004 ?        Ss   05:45   0:00 /usr/bin/git daemon --pid-file=/var/run/git-daemon.pid --user=git --group=git --reuseaddr --syslog --verbose --export-all --base-path=/var/lib/gitolite/repositories -- /var/lib/gitolite/repositories
git      28302  0.0  0.1  20048  1084 ?        S    05:45   0:00 git-daemon --pid-file=/var/run/git-daemon.pid --user=git --group=git --reuseaddr --syslog --verbose --export-all --base-path=/var/lib/gitolite/repositories -- /var/lib/gitolite/repositories
Comment 1 Göktürk Yüksek archtester gentoo-dev 2013-03-05 15:02:30 UTC
As a workaround, you can try to make /root world readable and executable (o+rx) and see if it helps.
Comment 2 Manuel Rüger (RETIRED) gentoo-dev 2013-03-05 21:29:10 UTC
Created attachment 341040 [details]
git-daemon-initd.patch

Thanks to some helpful hints from BtbN, I've moved the user/group/pid mgmt from git to startstopdaemon. Now everything works as expected.
Comment 3 Joerg Schaible 2013-03-23 13:37:57 UTC
Actually I think the problem lies deeper. The patch is only a workaround for a misbehavior of git-daemon. Currently it is no longer possible to run git-daemon with xinetd until you run this service as root.
Comment 4 Alexander Tsoy 2013-04-11 14:13:37 UTC
This also works:
$ sudo HOME=/home/git rc-service git-daemon restart

So probably a git daemon does not properly set its environment.
Comment 5 Justin Snelgrove 2013-07-07 19:29:36 UTC
This can be worked around without modifying the /etc/init.d/git-daemon by adding HOME="/path/to/git/user/home" to the end of /etc/conf.d/git-daemon. For example, adding HOME="/" for GIT_USER="nobody" makes git-daemon work as-expected.
Comment 6 WOLfgang Schricker 2013-09-12 14:32:09 UTC
(In reply to Justin J. Snelgrove from comment #5)
> For example, adding HOME="/" for GIT_USER="nobody" makes git-daemon work
> as-expected.

Yes, runs for me after git-daemon restart:

GITDAEMON_OPTS="--syslog --base-path=/var/lib/gitolite/repositories"
GIT_USER="git"
GIT_GROUP="git"
HOME="/var/lib/gitolite"
Comment 7 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-02-04 08:42:10 UTC
*** Bug 468512 has been marked as a duplicate of this bug. ***
Comment 8 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-02-06 13:46:22 UTC
Does this still happen with =dev-vcs/git-1.8.5.4? Please note that git-1.8.5.4 comes wit a rewritten init script and I need the results with that script without being modified in any way.
Comment 9 Robert Förster 2014-02-06 15:37:03 UTC
its not in the log on the server anymore, its displayed as a warning on pull: remote: warning: unable to access '/root/.config/git/attributes': Permission denied

not perfect, but it at least works now. (as in it doesn't error out)
still, adding HOME to /etc/conf.d/git-daemon as per comment #6 makes it go away completely
Comment 10 Timo Rothenpieler 2014-02-06 15:40:52 UTC
I still think the only real fix for this is not using the --user/--group option of git-daemon, and instead use start-stop-daemon to change the user/group, which makes it behave like expected.
Comment 11 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-02-07 07:58:59 UTC
+  07 Feb 2014; Lars Wendler <polynomial-c@gentoo.org> git-1.8.1.5.ebuild,
+  git-1.8.1.5-r1.ebuild, git-1.8.2.1.ebuild, git-1.8.3.2-r1.ebuild,
+  git-1.8.4.5.ebuild, git-1.8.5.3.ebuild, git-1.8.5.4.ebuild, git-9999.ebuild,
+  files/git-daemon-r1.initd:
+  Attempt to fix startup of git-daemon as non-root user (bug #460370). Added
+  sys-devel/gettext to DEPEND when nls USE flag is enabled.
+
Please re-emerge git-1.8.5.4 and try again. I've changed the init script (as suggested) to let start-stop-daemon assign the user/group.
Report your results here.
Comment 12 Timo Rothenpieler 2014-02-07 11:29:47 UTC
Yes, works without any error or warning with the new initscript for me.