Re: Git and securing a repository

On Wed, Jan 02, 2008 at 07:04:09 -0300, Gonzalo Garramuño wrote:

Felipe Balbi wrote:

quoted

it's easy on the full repository case, create different groups and
share git repositories by groups, after that chmod o-rwx -R
/path/to/repository.git.

Thanks.  I'll admit what you describe is somewhat discouraging, as what you 
are just describing is just managing user accounts or groups on the 
underlying OS.  That does not extend well to placing code on the net and 
has a bunch of administrative headaches.

I was really looking for a permission based system that was part of git 
itself (and thus more portable and easier to admin), and not the OS. 
Something akin to what perforce or even CVS can do.

You don't need to manage user accounts -- managing ssh public keys will do!

The git ssh access will always run one particular command (with path as
argument) to push and another particular command (again with path as
argument) to pull.

Thus you can prepare two scripts -- git-read-only will only run
$SSH_ORIGINAL_COMMAND if it is 'git-upload-pack <somearg>' and git-read-write
will also run it if it is 'git-receive-pack <somearg>'. The <somearg> is path
to the repository, so you can further limit on that. (Note: for recent git,
you need to recognize the 'git upload-pack' and 'git receive-pack' variants
too).

Now you can have each user create a ssh public key. You will put this key
into the .ssh/authorized_keys file on the server (therefore you only need
a single account there), with option command= specifying appropriate script
depending on what permissions the user should have. Than that user will be
able to push/pull (as set) via ssh using that public key and will not have
any other access to the server.

As a bonus, this way the users can't circumvent the pre-receive hooks
(perhaps you will allow each user to only push to a particular branch or
something) by manually changing the repository.

-- 
						 Jan 'Bulb' Hudec [off-list ref]