Re: git + ssh + key authentication feature-request

From: Junio C Hamano <junkio@cox.net>
Date: Feb 9, 2006, 00:40 UTC
Message-ID: <7vacd1mkk9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <slrndul2bq.2i8.mdw@metalzone.distorted.org.uk>

Mark Wooding <mdw@distorted.org.uk> writes:

> It's important that your users can't use this SSH access to mess with
> the shared user's SSH configuration itself, but, hey, that sort of
> restricted access is what git-daemon is for, right?

Correct modulo s/git-daemon/git-shell/.

> I think the problem there is more that the commits themselves were
> created elsewhere, where this server wasn't watching, and therefore it
> pretty much has to take the committer and author information there on
> trust.

That's an different issue. Anybody could create bogus commits all they want based on somebody else's history. Making refs/{heads,tags}/ pointers to point at the tip of a development tail that contains such bogus commits is something you would want to have control upon.

For example, Documentation/howto/update-hook-example shows Carl's idea to implement access control using the unix user identity (because it assumes you set up one home directory per developer to use public key authentication to cause sshd to give a true unix uid to an incoming connection) to make sure who can update which head. By updating a branch head, the developer is asserts that the development trail that led to it is something she feels valid.

Now, you brought up an interesting way to do this without using unix uid. Some sshd installations do not honour environment= settings, but that problem aside, you could define a token, say GIT_USER, with different value on each line in the shared authorized_keys file so that you can distinguish incoming developers that share the same "home directory", and change the example hook Carl gave us to use that token instead of the unix user identity. I'd imagine that would work quite well.