On Mon, 28 Jan 2008, Shawn O. Pearce wrote:
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.
For what it's worth, if you haven't seen gitosis yet, you might want to
take a look - at least it makes managing the keys easy.
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
has a nice tutorial.
-- Asheesh.
--
He who despairs over an event is a coward, but he who holds hopes for
the human condition is a fool.
-- Albert Camus
-
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
