Re: Git and securing a repository

[Bruno Cesar Ribas <ribas@c3sl.ufpr.br>]

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 <jnareb@gmail.com> wrote:
> > Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> > > David Symonds wrote:
> > >>
> > >> 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.
> 
> > > 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.
>  
> > 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.
>  
> > 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