Hi, On Sun, 27 Jan 2008, Shawn O. Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. > 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. > 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). > 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. > 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 - 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
