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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 27, 2008, 18:51 UTC
Message-ID: <alpine.LSU.1.00.0801271841230.23907@racer.site>
In-Reply-To: <20080127173212.GW24004@spearce.org>

Hi,

On Sun, 27 Jan 2008, Shawn O. Pearce wrote:

Show 34 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 27 Jan 2008, Shawn O. Pearce wrote:
> > 
> > >     ## Owner (not jdoe)
> > >     ##
> > >   cat >foo.git/hooks/update <<'EOF'
> > >   #!/bin/sh
> > >   test -z "$GIT_REMOTE_USER" || exit
> > >   case "$GIT_REMOTE_USER" in
> > >   jdoe)     exit 0;;
> > >   spearce)  exit 0;;
> > >   *)        exit 1
> > >   esac
> > >   EOF
> > >   chmod u+x foo.git/hooks/update
> > >   chmod 700 foo.git
> > > 
> > >   git daemon \
> > >       --export-all \
> > >       --enable=receive-pack \
> > >       --base=`pwd` \
> > >       --listen=/tmp/shawn-git
> > > 
> > >     ## Other User
> > >     ##
> > >   git push jdoe@server:/tmp/shawn-git/foo.git master
> > 
> > I probably miss something, but if you already go through SSH, the 
> > $USER is set appropriately, no?
> 
> 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.

Show 10 quoted lines

> So if you want to give out write access, but have it be limited to what 
> `git receive-pack` will permit (especially when coupled with an update 
> hook like contrib/hooks/update-paranoid) you need to limit what a user 
> can do to *only* executing git-receive-pack, but you also need to allow 
> that receive-pack to actually have write permission on the repository.
> 
> So you come down to four options:
> 
> 1) Make git-receive-pack setuid to the repository owner.
>    This is uh, ugly.

Concur.

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

Show 5 quoted lines

> 3) Export git-daemon over TCP and --enable=receive-pack.
>    This doesn't get us any authentication.  Sure the
>    user is limited to what the update hook allows, but
>    the update hook has no way to trust who the remote
>    peer is.  You might as well not bother.

Right. --enable=receive-pack was meant for environments where you have to trust everybody anyway (think "Visual" SourceSafe, or PVCS with repositories on network shares).

Show 5 quoted lines

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

Show 5 quoted lines

> If we don't do something like this then I think we need to teach 
> git-daemon how to accept SSL connections, and then once you give it SSL 
> you need to implement peer authentication by certificates, and then have 
> git_connect() in connect.c also implement setting up SSL connections, 
> and doing peer authentication with certificates.  Ick.

I never tried anything like this, but it should not be _that_ difficult, should it? Of course, I should read up on it before I say something about it first ;-)

Ciao, Dscho