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. > So you could do without git-daemon entirely, and replace the > GIT_REMOTE_USER variable in the hook by USER. No, you can't. If you give write access to a repository such that a user can push into it, there is little point in using the update hook to control access to the repository. Why? Because anyone with write access can just use the standard Git commands (e.g. `git --git-dir=foo.git branch -D next`) to maniplate the repository in ways that the update hook wouldn't like. 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. 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. 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. 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. 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. Relying on SSH is the better approach in my opinion. It comes with a set of well trusted servers (OpenSSH) and user client tools that many users and administrators already understand (e.g. ssh-agent). Someone on #git yesterday mentioned that a problem half-deferred (user authentication) is a problem half-solved. I've half-deferred the authentication problem to SSH, much as we already have it deferred to SSH... :-) -- Shawn. - 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
