Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. - 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
