Re: Git and securing a repository

I lost ohter mails, so replying here =)

I wrote sometime ago i wrote[1] a bunch of BASH scripts to manage SSH_ACL and "internal"
plugin is to manage GIT repositories. 
It is simple and you can grant access to a user for R or W. And there is NO
need to create more users just a "git" user is nice.

I'm re-writing it to become more flexible about configuration and to add more
plugins.

We are using it at C3SL[2] to manage our projects and Write permissions are
set because we don't want some developers pushing to anothers projects.

bruno

[1]http://www.inf.ufpr.br/ribas/ssh_acl/
[2]http://www.c3sl.ufpr.br
On Wed, Jan 02, 2008 at 10:58:38PM -0500, Shawn O. Pearce wrote:

Jakub Narebski [off-list ref] wrote:

quoted

Gonzalo Garramuño [off-list ref] writes:

quoted

David Symonds wrote:

quoted

You can do arbitrarily-fine-grained authentication via the
pre-receive hook.

Can you provide some more info?  Looking at the kernel.org git docs,
the pre-receive hook seems very limited as no parameters are allowed.
So I'm not sure how an authentication system could be created.

If you read the documentation carefully you will note that the
pre-receive hook receives input on stdin; 1 line of data per ref
that is being pushed with the old/new SHA-1 values and the ref
name.  The hook exits 0 to allow all changes to take place and
can exit > 0 to abort and disallow all updates.

This is a "batch" form of the update hook.

quoted

quoted

It also seems to be a push hook only (not invoked on pulls).

Some of read-only (fetch only) access protocols do not support
authentication: http, ftp, rsync, git. Authentication is provided only
for access via ssh and for push via https (WebDAV).

Authentication could be supported for http, ftp, or ssh based fetch,
but there you are relying on the server that provides access to do
the authentication and authorization for you; typically that will
boil down to UNIX filesystem read permission.  Though with HTTP
and a fancy Apache config it doesn't have to be.
 

quoted

There is example update hook in contrib/hooks, named update-paranoid,
which could be base of what you want. Note that you probably rather
use newer pre-receive hook instead of older update hook.

update-paranoid uses the update hook rather than pre-receive to
allow it to allow/deny on a per-ref basis.  One of the flaws of
the pre-receive hook "API" is it is an all-or-nothing proposition.

So by using the "older" update hook update-paranoid can make its
decision on a per-ref basis and allow some refs to change in this
push but abort/deny others.  I find that useful but not everyone
might.
 

quoted

AFAIK both update and pre-receive hooks are invoked also on fetch...
but I might be mistaken.

No, they are *not* invoked on fetch.  Currently no hooks execute
during fetch; either on the server *or* on the client side of
the connection.

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Bruno Ribas - ribas@c3sl.ufpr.br
http://web.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br