Re: [RFC] Secure central repositories by UNIX socket authentication

["Shawn O. Pearce" <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 27 Jan 2008, Shawn O. Pearce wrote:
> > 
> > Sure, $USER is set.  For "jdoe".  But due to the "chmod 700 foo.git" 
> > above jdoe isn't actually allowed access to the repository directory. So 
> > it doesn't matter what $USER is set to, jdoe cannot get to the files of 
> > the repository.
> 
> Ah, that's what I missed.  I thought you already used git-shell, and did 
> not really read the chmod part.

No, I'm not using git-shell.  I'm actually currently using a setuid
git-receive-pack, which we've both agreed is horribly ugly.  I want
to get away from that mess.
 
> > 2) Use the SSH key feature to have remote users login as
> >    the repository owner, but use the authorized_keys file
> >    to force them to only execute git-shell.
> >    This is uh, ugly, especially with 50+ users.
> 
> Slight variation: do not permit other users access to your machine, except 
> via git-shell.  Then you don't need chmod 0700.

This isn't an option.  At least 10% of the users need a real shell
on this system, but cannot be trusted to not directly edit the
repository.  I'm also not able to get them different user accounts
(one for git-shell, one for normal shell) because giving the same
human two different user accounts on the same UNIX system will
cause the world to explode.  At least according to some management
people who get paid 3x what I get paid.

Of course, note those same people have also said that a SAMBA server
cannot run on a system unless it is a SAMBA server.  Catch-22.
You cannot run SAMBA unless you are already running SAMBA.  :-\

> > 4) Add full user authentication to git-daemon and then do #3.
> >    The user authentication can provide data down into the update
> >    hook, such as by setting the $GIT_REMOTE_USER environment
> >    variable.  That's basically this change, except I'm using bog
> >    standard SSH to perform the authentication for me.
> 
> AFAIR the plan was to keep git-daemon as simple and stupid as possible; in 
> particular _not_ to add any authentication.

Yup.  I think its smart.  Defer authentication off to the standard OS
tools, so we don't have to deal with it in git itself.

Yet I'm offering a patch for comment that adds some level of
authentication to git-daemon.  At least it still just relies on
UNIX uids and doesn't actually try to link to PAM.  :-)
 
-- 
Shawn.