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@xxxxxxxxx> wrote: > > Gonzalo Garramuño <ggarra@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Bruno Ribas - ribas@xxxxxxxxxxxx http://web.inf.ufpr.br/ribas C3SL: http://www.c3sl.ufpr.br - 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
