Re: git + ssh + key authentication feature-request

[Junio C Hamano <junkio@cox.net>]

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.