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

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Hmm.  core.sharedrepository is sometimes a bad solution.
> >
> > core.sharedrepository means I need to give write access to both the
> > refs database and the object database to all members of the project.
> > Some of whom may not be able to be trusted with tools like "rm",
> > but who need real shell access to that system anyway.  And sometimes
> > management won't allow users to have two accounts on the same system
> > (one that is fixed to git-shell, and one that has a real shell)
> > because the world would implode if a user was given two different
> > accounts for two different access purposes.
> 
> Ok, that was the motiviation I did not get from your original
> message.  It begins to make sense somewhat.
> 
> Another approach to do the same I can think of, without having
> to add 50 new accounts for 50 users, would be to collect a ssh
> key from each of these 50 users, and have 1 line per user in the
> authorized_keys file of gitadmin.gitadmin user (who owns the
> repository with the paranoia hook that decides the authorization
> aspect of the repository).  The authentication would come from
> the environment="Name=value" option in the authorized_keys file.
> Each of your aunt tillies can push or fetch over ssh using the
> key she has in the gitadmin.gitadmin's authorized_keys file.

Yea.  The downside to this is we have to maintain that
authorized_keys file.  Today each user can generate their
own SSH key and upload to their own authorized_keys file.

I've had enough cases of users losing their SSH key and
needing to recreate it that I'd rather not have to manage
a 50 user long authorized_keys file.

I'm also not sure of what the performance implication is to SSH for
authentication with 50 public keys in a single file.  Does it slow
down as its running a check against each key, or is there something
smarter to filter the keys?  From the description of the format in
the OpenSSH manpage it doesn't look like its possible other than
to probe every key in turn for every authentication attempt.

In other words, the authorized_keys is a nice feature, but it seems
like its more useful for a remote backup job logging in as root, or a
"vacation mode" where a coworker is permitted to execute a specific
command while you are away.  But maybe I'm missing something.
 
> I suspect the "hackiness" factor from the aesthetics viewpoint
> is probably about the same, but this would work with the current
> code without patches, no?

Yes, it would, obviously.  But it has the downside of needing to
manage a single common authorized_keys file.  Which is something
I think I'd like to avoid.

It also doesn't do anything about upload-pack, as that has no hook
to perform authorization.  Of course just adding some sort of ref
filtering hook to upload-pack is still a smaller patch than adding
all this UNIX socket redirection and an upload-pack hook.  :)

-- 
Shawn.