Re: [git] regression: 96b9e0e3 config: treat user and xdg config permission problems as errors busted git-daemon

2013-04-11 Thread Mike Galbraith
On Thu, 2013-04-11 at 01:42 -0400, Jeff King wrote: 
 On Thu, Apr 11, 2013 at 05:39:43AM +0200, Mike Galbraith wrote:
 
 ALLOWED_ENV=PATH HOME
 HOME=/
  
  I can work around it by changing the init script to use su - git -c bla
  bla to launch the thing, instead of using --user=git --group=daemon,
  but that's just a bandaid for the busted environment setup those
  switches were supposed to make happen, no?
 
 Yeah, I think the bug here is that git-daemon should be setting $HOME
 when it switches privileges with --user. Does this patch fix it for you?
 
 diff --git a/daemon.c b/daemon.c
 index 6aeddcb..a4451fd 100644
 --- a/daemon.c
 +++ b/daemon.c
 @@ -1091,6 +1091,7 @@ static void drop_privileges(struct credentials *cred)
   if (cred  (initgroups(cred-pass-pw_name, cred-gid) ||
   setgid (cred-gid) || setuid(cred-pass-pw_uid)))
   die(cannot drop privileges);
 + setenv(HOME, cred-pass-pw_dir, 1);
  }
  
  static struct credentials *prepare_credentials(const char *user_name,
 
 I guess that would technically break anybody who was trying to do
 something clever with HOME (i.e., point it somewhere besides --user's
 HOME where they had put some config files). But the obvious clever
 thing would be to also set the user's passwd homedir to the same place.

I did exactly that yesterday, and it didn't work, which rather surprised
me.  Let me double check that I didn't screw trivial all up...

Heh, if ya don't plunk new binary into the old oddly placed bucket :)
Yeah, that works just fine.

-Mike 


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [git] regression: 96b9e0e3 config: treat user and xdg config permission problems as errors busted git-daemon

2013-04-10 Thread W. Trevor King
On Wed, Apr 10, 2013 at 07:33:35AM +0200, Mike Galbraith wrote:
 /usr/lib/git/git-daemon --syslog --detach --reuseaddr --user=git 
 --group=daemon --pid-file=/var/run/git-daemon.pid --export-all --user-path 
 --enable=receive-pack
 
 Try to pull as root or normal user results in:
 
 [pid 26786] access(/root/.config/git/config, R_OK) = -1 EACCES (Permission 
 denied)
 [pid 26786] write(2, fatal: unable to access '/root/, 70) = 70
 [pid 26785] ... read resumed fatal: unable to access '/root/, 4096) = 
 70
 [pid 26786] exit_group(128)
 
 Bisection fingered this commit, though it looks like it's really due to
 not forgetting who it was at birth.  It's not root, so has no business
 rummaging around in /root.  It used to not care, but this commit made
 go away while looking for non-existent config file terminal.

I ran into this too, although I'm running git-daemon via spawn-fcgi.
In order to convince newer Gits that you know what you're doing, you
just need to set HOME to somewhere Git can look.  For example:

  HOME=/ /usr/lib/git/git-daemon …

should work.  On Gentoo, I added the following to
/etc/conf.d/spawn-fcgi.fcgiwrap:

  ALLOWED_ENV=PATH HOME
  HOME=/

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature


Re: [git] regression: 96b9e0e3 config: treat user and xdg config permission problems as errors busted git-daemon

2013-04-10 Thread Mike Galbraith
On Wed, 2013-04-10 at 09:56 -0400, W. Trevor King wrote: 
 On Wed, Apr 10, 2013 at 07:33:35AM +0200, Mike Galbraith wrote:
  /usr/lib/git/git-daemon --syslog --detach --reuseaddr --user=git 
  --group=daemon --pid-file=/var/run/git-daemon.pid --export-all --user-path 
  --enable=receive-pack
  
  Try to pull as root or normal user results in:
  
  [pid 26786] access(/root/.config/git/config, R_OK) = -1 EACCES 
  (Permission denied)
  [pid 26786] write(2, fatal: unable to access '/root/, 70) = 70
  [pid 26785] ... read resumed fatal: unable to access '/root/, 4096) 
  = 70
  [pid 26786] exit_group(128)
  
  Bisection fingered this commit, though it looks like it's really due to
  not forgetting who it was at birth.  It's not root, so has no business
  rummaging around in /root.  It used to not care, but this commit made
  go away while looking for non-existent config file terminal.
 
 I ran into this too, although I'm running git-daemon via spawn-fcgi.
 In order to convince newer Gits that you know what you're doing, you
 just need to set HOME to somewhere Git can look.  For example:
 
   HOME=/ /usr/lib/git/git-daemon …
 
 should work.  On Gentoo, I added the following to
 /etc/conf.d/spawn-fcgi.fcgiwrap:
 
   ALLOWED_ENV=PATH HOME
   HOME=/

I can work around it by changing the init script to use su - git -c bla
bla to launch the thing, instead of using --user=git --group=daemon,
but that's just a bandaid for the busted environment setup those
switches were supposed to make happen, no?

-Mike

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [git] regression: 96b9e0e3 config: treat user and xdg config permission problems as errors busted git-daemon

2013-04-10 Thread Jeff King
On Thu, Apr 11, 2013 at 05:39:43AM +0200, Mike Galbraith wrote:

ALLOWED_ENV=PATH HOME
HOME=/
 
 I can work around it by changing the init script to use su - git -c bla
 bla to launch the thing, instead of using --user=git --group=daemon,
 but that's just a bandaid for the busted environment setup those
 switches were supposed to make happen, no?

Yeah, I think the bug here is that git-daemon should be setting $HOME
when it switches privileges with --user. Does this patch fix it for you?

diff --git a/daemon.c b/daemon.c
index 6aeddcb..a4451fd 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1091,6 +1091,7 @@ static void drop_privileges(struct credentials *cred)
if (cred  (initgroups(cred-pass-pw_name, cred-gid) ||
setgid (cred-gid) || setuid(cred-pass-pw_uid)))
die(cannot drop privileges);
+   setenv(HOME, cred-pass-pw_dir, 1);
 }
 
 static struct credentials *prepare_credentials(const char *user_name,

I guess that would technically break anybody who was trying to do
something clever with HOME (i.e., point it somewhere besides --user's
HOME where they had put some config files). But the obvious clever
thing would be to also set the user's passwd homedir to the same place.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html