{"thread":{"id":"11446","subject":"Git and securing a repository","startedAt":"2008-01-02T06:34:04Z","lastAt":"2008-01-03T09:36:48Z","messageCount":18,"participants":["Gonzalo Garramuño","Felipe Balbi","David Symonds","Jakub Narebski","Daniel Barkalow","Jan Hudec","Gregory Jefferis","Linus Torvalds","Shawn O. Pearce","Bruno Cesar Ribas","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64319","messageId":"31e679430801012234x20bbebe7vb496a338bf2699d5@mail.gmail.com","threadId":"11446","inReplyTo":"477B39B5.5010107@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"Felipe Balbi","fromEmail":"felipebalbi@users.sourceforge.net","sentAt":"2008-01-02T06:34:04Z","receivedAt":"2008-01-02T06:34:04Z","isPatch":false,"sender":{"key":"felipebalbi@users.sourceforge.net","avatar":null},"body":"On Jan 2, 2008 2:13 AM, Gonzalo Garramuño wrote:\n>\n> I've been using git for some time and love it. For open source projects\n> there's clearly nothing currently better.\n>\n> However, I am now using git for proprietary elements, which in the\n> future I may need or want to partially restrict access to. The idea\n> being that at my company some (junior) developers should not be given\n> access to some elements. That means either that some full git\n> repository should be password protected or even portions of the same\n> repository.\n>\n> Another desirable way to protect elements might be only giving\n> clone/pull access to a repository (or portion of it) but not permissions\n> to push in changes.\n\npush access is only available through ssh, so if your developer\ndoesn't have a ssh account on the server, he can't push code to it\n\n>\n> I have not seen or read much about how git deals with accesses and\n> permissions. Can anyone point me to some documentation if some or all\n> of this is possible?\n\nit's easy on the full repository case, create different groups and\nshare git repositories by groups, after that chmod o-rwx -R\n/path/to/repository.git.\n\nIf a user is not the owner nor is part of that group in particular, it\nwouldn't be able to push any code to the repository.\n\nbtw, if you don't start git-daemon you could use ssh to pull code as well.\n\nthinking on the partial repository access, maybe git submodule would\nhelp, but i've never used it.\n\n-- \nBest Regards,\n\nFelipe Balbi\nfelipebalbi@users.sourceforge.net\n"},{"id":"64318","messageId":"477B39B5.5010107@advancedsl.com.ar","threadId":"11446","inReplyTo":null,"subject":"Git and securing a repository","fromName":"Gonzalo Garramuño","fromEmail":"ggarra@advancedsl.com.ar","sentAt":"2008-01-02T07:13:57Z","receivedAt":"2008-01-02T07:13:57Z","isPatch":false,"sender":{"key":"ggarra@advancedsl.com.ar","avatar":null},"body":"\nI've been using git for some time and love it. For open source projects \nthere's clearly nothing currently better.\n\nHowever, I am now using git for proprietary elements, which in the \nfuture I may need or want to partially restrict access to. The idea \nbeing that at my company some (junior) developers should not be given \naccess to some elements. That means either that some full git \nrepository should be password protected or even portions of the same \nrepository.\n\nAnother desirable way to protect elements might be only giving \nclone/pull access to a repository (or portion of it) but not permissions \nto push in changes.\n\nI have not seen or read much about how git deals with accesses and \npermissions. Can anyone point me to some documentation if some or all \nof this is possible?\n\n\n-- \nGonzalo Garramuño\nggarra@advancedsl.com.ar\n\nAMD4400 - ASUS48N-E\nGeForce7300GT\nXubuntu Gutsy\n"},{"id":"64324","messageId":"ee77f5c20801020126n1776d625ya6928c2e4bfdf497@mail.gmail.com","threadId":"11446","inReplyTo":"477B6199.6070601@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-01-02T09:26:29Z","receivedAt":"2008-01-02T09:26:29Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Jan 2, 2008 9:04 PM, Gonzalo Garramuño wrote:\n> Felipe Balbi wrote:\n> >\n> > it's easy on the full repository case, create different groups and\n> > share git repositories by groups, after that chmod o-rwx -R\n> > /path/to/repository.git.\n> >\n>\n> Thanks. I'll admit what you describe is somewhat discouraging, as what\n> you are just describing is just managing user accounts or groups on the\n> underlying OS. That does not extend well to placing code on the net and\n> has a bunch of administrative headaches.\n>\n> I was really looking for a permission based system that was part of git\n> itself (and thus more portable and easier to admin), and not the OS.\n> Something akin to what perforce or even CVS can do.\n\nYou can do arbitrarily-fine-grained authentication via the pre-receive hook.\n\n\nDave.\n"},{"id":"64323","messageId":"477B6199.6070601@advancedsl.com.ar","threadId":"11446","inReplyTo":"31e679430801012234x20bbebe7vb496a338bf2699d5@mail.gmail.com","subject":"Re: Git and securing a repository","fromName":"Gonzalo Garramuño","fromEmail":"ggarra@advancedsl.com.ar","sentAt":"2008-01-02T10:04:09Z","receivedAt":"2008-01-02T10:04:09Z","isPatch":false,"sender":{"key":"ggarra@advancedsl.com.ar","avatar":null},"body":"Felipe Balbi wrote:\n> \n> it's easy on the full repository case, create different groups and\n> share git repositories by groups, after that chmod o-rwx -R\n> /path/to/repository.git.\n> \n\nThanks. I'll admit what you describe is somewhat discouraging, as what \nyou are just describing is just managing user accounts or groups on the \nunderlying OS. That does not extend well to placing code on the net and \nhas a bunch of administrative headaches.\n\nI was really looking for a permission based system that was part of git \nitself (and thus more portable and easier to admin), and not the OS. \nSomething akin to what perforce or even CVS can do.\n\n\n-- \nGonzalo Garramuño\nggarra@advancedsl.com.ar\n\nAMD4400 - ASUS48N-E\nGeForce7300GT\nXubuntu Gutsy\n"},{"id":"64325","messageId":"477B69ED.3090107@advancedsl.com.ar","threadId":"11446","inReplyTo":"ee77f5c20801020126n1776d625ya6928c2e4bfdf497@mail.gmail.com","subject":"Re: Git and securing a repository","fromName":"Gonzalo Garramuño","fromEmail":"ggarra@advancedsl.com.ar","sentAt":"2008-01-02T10:39:41Z","receivedAt":"2008-01-02T10:39:41Z","isPatch":false,"sender":{"key":"ggarra@advancedsl.com.ar","avatar":null},"body":"David Symonds wrote:\n> \n> You can do arbitrarily-fine-grained authentication via the pre-receive hook.\n> \n\nCan you provide some more info? Looking at the kernel.org git docs, the \npre-receive hook seems very limited as no parameters are allowed. So \nI'm not sure how an authentication system could be created.\n\nIt also seems to be a push hook only (not invoked on pulls).\n\n\n\n-- \nGonzalo Garramuño\nggarra@advancedsl.com.ar\n\nAMD4400 - ASUS48N-E\nGeForce7300GT\nXubuntu Gutsy\n"},{"id":"64332","messageId":"m3ir2co5s4.fsf@roke.D-201","threadId":"11446","inReplyTo":"477B69ED.3090107@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-02T10:51:37Z","receivedAt":"2008-01-02T10:51:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Gonzalo Garramuño writes:\n\n> David Symonds wrote:\n>>\n>> You can do arbitrarily-fine-grained authentication via the\n>> pre-receive hook.\n>>\n> \n> Can you provide some more info? Looking at the kernel.org git docs,\n> the pre-receive hook seems very limited as no parameters are allowed.\n> So I'm not sure how an authentication system could be created.\n> \n> It also seems to be a push hook only (not invoked on pulls).\n\nSome of read-only (fetch only) access protocols do not support\nauthentication: http, ftp, rsync, git. Authentication is provided only\nfor access via ssh and for push via https (WebDAV).\n\nThere is example update hook in contrib/hooks, named update-paranoid,\nwhich could be base of what you want. Note that you probably rather\nuse newer pre-receive hook instead of older update hook.\n\nAFAIK both update and pre-receive hooks are invoked also on fetch...\nbut I might be mistaken.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"64336","messageId":"alpine.LNX.1.00.0801021058030.13593@iabervon.org","threadId":"11446","inReplyTo":"477B39B5.5010107@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-01-02T16:18:20Z","receivedAt":"2008-01-02T16:18:20Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 2 Jan 2008, Gonzalo Garramuño wrote:\n\n> I've been using git for some time and love it. For open source projects\n> there's clearly nothing currently better.\n> \n> However, I am now using git for proprietary elements, which in the future I\n> may need or want to partially restrict access to. The idea being that at my\n> company some (junior) developers should not be given access to some elements.\n> That means either that some full git repository should be password protected\n> or even portions of the same repository.\n> \n> Another desirable way to protect elements might be only giving clone/pull\n> access to a repository (or portion of it) but not permissions to push in\n> changes.\n\nIn order to understand the security model, you have to remember that git \nis designed as a distributed system. Authorization is fundamentally not at \na project level, but rather at a repository level, and clones are all \ndifferent repositories. This makes portability of the mechanism less \nimportant, because a particular set of authorization rules only applies to \na particular repository, which is going to be on some single system.\n\nFor that matter, git doesn't run with any special privileges in general; \nif a user can affect the repository with git operations, that user can \naffect the repository by hand, so git-specific rules aren't helpful. \n(Although I suppose it would be theoretically useful to make git-shell, \nthe shell that only runs git programs, able to apply restrictions, since \nit is used in a context where the user doesn't have any other access to \nthe filesystem.)\n\nFor read access restrictions, you want to use submodules (or entirely \nseparate projects); git is fundamentally unhappy running with less than \nall of the project accessible, except for when a project references \nanother project with submodules. And, of course, if the code base is such \nthat users can do useful work without any access to some of the files, \nthose files must be optional and somewhat separate from the necessary \nportions, and it makes sense to handle them separately anyway.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"64347","messageId":"20080102193114.GA4608@efreet.light.src","threadId":"11446","inReplyTo":"477B6199.6070601@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-01-02T19:31:14Z","receivedAt":"2008-01-02T19:31:14Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Jan 02, 2008 at 07:04:09 -0300, Gonzalo Garramuño wrote:\n> Felipe Balbi wrote:\n>>\n>> it's easy on the full repository case, create different groups and\n>> share git repositories by groups, after that chmod o-rwx -R\n>> /path/to/repository.git.\n>>\n>\n> Thanks. I'll admit what you describe is somewhat discouraging, as what you \n> are just describing is just managing user accounts or groups on the \n> underlying OS. That does not extend well to placing code on the net and \n> has a bunch of administrative headaches.\n>\n> I was really looking for a permission based system that was part of git \n> itself (and thus more portable and easier to admin), and not the OS. \n> Something akin to what perforce or even CVS can do.\n\nYou don't need to manage user accounts -- managing ssh public keys will do!\n\nThe git ssh access will always run one particular command (with path as\nargument) to push and another particular command (again with path as\nargument) to pull.\n\nThus you can prepare two scripts -- git-read-only will only run\n$SSH_ORIGINAL_COMMAND if it is 'git-upload-pack ' and git-read-write\nwill also run it if it is 'git-receive-pack '. The is path\nto the repository, so you can further limit on that. (Note: for recent git,\nyou need to recognize the 'git upload-pack' and 'git receive-pack' variants\ntoo).\n\nNow you can have each user create a ssh public key. You will put this key\ninto the .ssh/authorized_keys file on the server (therefore you only need\na single account there), with option command= specifying appropriate script\ndepending on what permissions the user should have. Than that user will be\nable to push/pull (as set) via ssh using that public key and will not have\nany other access to the server.\n\nAs a bonus, this way the users can't circumvent the pre-receive hooks\n(perhaps you will allow each user to only push to a particular branch or\nsomething) by manually changing the repository.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"64349","messageId":"C3A19969.1083F%jefferis@gmail.com","threadId":"11446","inReplyTo":"20080102193114.GA4608@efreet.light.src","subject":"Re: Git and securing a repository","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-02T19:41:29Z","receivedAt":"2008-01-02T19:41:29Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"On 2/1/08 19:31, \"Jan Hudec\" wrote:\n\n> \n> You don't need to manage user accounts -- managing ssh public keys will do!\n\nHas anyone used gitosis?\n\nhttp://eagain.net/gitweb/?p=gitosis.git\n\nhttp://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-w\nay\n\nIt seems to make setting up this kind of approach easier.\n\nBest,\n\nGreg.\n\n-- \nGregory Jefferis, PhD and:\nResearch Fellow\nDepartment of Zoology St John's College\nDowning Street Cambridge\nCambridge, CB2 3EJ CB2 1TP \n"},{"id":"64358","messageId":"alpine.LFD.1.00.0801021406020.3010@woody.linux-foundation.org","threadId":"11446","inReplyTo":"477B6199.6070601@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-02T22:17:43Z","receivedAt":"2008-01-02T22:17:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 2 Jan 2008, Gonzalo Garramu?o wrote:\n> \n> I was really looking for a permission based system that was part of git itself\n> (and thus more portable and easier to admin), and not the OS. Something akin\n> to what perforce or even CVS can do.\n\nWell, git by design doesn't do that. \n\nThat doesn't mean that it has to be OS-level permissions (in fact, it \ngenerally shouldn't), it just means that git wasn't really meant to care \nabout permissions itself, and you the user management and permissions \nshould come from \"outside\".\n\nThat outside *can* be OS-level things like just permissions on files, but \nmore commonly it's things like SSH keys and using the git hooks. In other \nwords, pretty much by design, git is meant to be the *core* SCM \ninfrastructure, and then you layer your user management on top of it as a \n*separate* layer.\n\nAn example of that would probably be gitosis, but I haven't used it \nmyself. For the kernel, people literally tend to just use SSH accounts, \nand not any central repository at all (ie the kind of crazy \"central repo \naccess control rules\" that centralized repos need are just not necessary \nat all in a more distributed usage model).\n\nSee \n\n\thttp://eagain.net/gitweb/?p=gitosis.git\n\thttp://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way\n\nfor a quick starting point on gitosis, if that suits your needs (there's \nmore, google is your friend).\n\n\t\t\tLinus\n"},{"id":"64366","messageId":"20080103035838.GA24004@spearce.org","threadId":"11446","inReplyTo":"m3ir2co5s4.fsf@roke.D-201","subject":"Re: Git and securing a repository","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-01-03T03:58:38Z","receivedAt":"2008-01-03T03:58:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Gonzalo Garramuño writes:\n> > David Symonds wrote:\n> >>\n> >> You can do arbitrarily-fine-grained authentication via the\n> >> pre-receive hook.\n> > \n> > Can you provide some more info? Looking at the kernel.org git docs,\n> > the pre-receive hook seems very limited as no parameters are allowed.\n> > So I'm not sure how an authentication system could be created.\n\nIf you read the documentation carefully you will note that the\npre-receive hook receives input on stdin; 1 line of data per ref\nthat is being pushed with the old/new SHA-1 values and the ref\nname. The hook exits 0 to allow all changes to take place and\ncan exit > 0 to abort and disallow all updates.\n\nThis is a \"batch\" form of the update hook.\n\n> > It also seems to be a push hook only (not invoked on pulls).\n> \n> Some of read-only (fetch only) access protocols do not support\n> authentication: http, ftp, rsync, git. Authentication is provided only\n> for access via ssh and for push via https (WebDAV).\n\nAuthentication could be supported for http, ftp, or ssh based fetch,\nbut there you are relying on the server that provides access to do\nthe authentication and authorization for you; typically that will\nboil down to UNIX filesystem read permission. Though with HTTP\nand a fancy Apache config it doesn't have to be.\n \n> There is example update hook in contrib/hooks, named update-paranoid,\n> which could be base of what you want. Note that you probably rather\n> use newer pre-receive hook instead of older update hook.\n\nupdate-paranoid uses the update hook rather than pre-receive to\nallow it to allow/deny on a per-ref basis. One of the flaws of\nthe pre-receive hook \"API\" is it is an all-or-nothing proposition.\n\nSo by using the \"older\" update hook update-paranoid can make its\ndecision on a per-ref basis and allow some refs to change in this\npush but abort/deny others. I find that useful but not everyone\nmight.\n \n> AFAIK both update and pre-receive hooks are invoked also on fetch...\n> but I might be mistaken.\n\nNo, they are *not* invoked on fetch. Currently no hooks execute\nduring fetch; either on the server *or* on the client side of\nthe connection.\n\n-- \nShawn.\n"},{"id":"64370","messageId":"20080103043009.GA365@c3sl.ufpr.br","threadId":"11446","inReplyTo":"20080103035838.GA24004@spearce.org","subject":"Re: Git and securing a repository","fromName":"Bruno Cesar Ribas","fromEmail":"ribas@c3sl.ufpr.br","sentAt":"2008-01-03T04:30:09Z","receivedAt":"2008-01-03T04:30:09Z","isPatch":false,"sender":{"key":"ribas@c3sl.ufpr.br","avatar":null},"body":"I lost ohter mails, so replying here =)\n\nI wrote sometime ago i wrote[1] a bunch of BASH scripts to manage SSH_ACL and \"internal\"\nplugin is to manage GIT repositories. \nIt is simple and you can grant access to a user for R or W. And there is NO\nneed to create more users just a \"git\" user is nice.\n\nI'm re-writing it to become more flexible about configuration and to add more\nplugins.\n\nWe are using it at C3SL[2] to manage our projects and Write permissions are\nset because we don't want some developers pushing to anothers projects.\n\nbruno\n\n[1]http://www.inf.ufpr.br/ribas/ssh_acl/\n[2]http://www.c3sl.ufpr.br\nOn Wed, Jan 02, 2008 at 10:58:38PM -0500, Shawn O. Pearce wrote:\n> Jakub Narebski wrote:\n> > Gonzalo Garramuño writes:\n> > > David Symonds wrote:\n> > >>\n> > >> You can do arbitrarily-fine-grained authentication via the\n> > >> pre-receive hook.\n> > > \n> > > Can you provide some more info? Looking at the kernel.org git docs,\n> > > the pre-receive hook seems very limited as no parameters are allowed.\n> > > So I'm not sure how an authentication system could be created.\n> \n> If you read the documentation carefully you will note that the\n> pre-receive hook receives input on stdin; 1 line of data per ref\n> that is being pushed with the old/new SHA-1 values and the ref\n> name. The hook exits 0 to allow all changes to take place and\n> can exit > 0 to abort and disallow all updates.\n> \n> This is a \"batch\" form of the update hook.\n> \n> > > It also seems to be a push hook only (not invoked on pulls).\n> > \n> > Some of read-only (fetch only) access protocols do not support\n> > authentication: http, ftp, rsync, git. Authentication is provided only\n> > for access via ssh and for push via https (WebDAV).\n> \n> Authentication could be supported for http, ftp, or ssh based fetch,\n> but there you are relying on the server that provides access to do\n> the authentication and authorization for you; typically that will\n> boil down to UNIX filesystem read permission. Though with HTTP\n> and a fancy Apache config it doesn't have to be.\n> \n> > There is example update hook in contrib/hooks, named update-paranoid,\n> > which could be base of what you want. Note that you probably rather\n> > use newer pre-receive hook instead of older update hook.\n> \n> update-paranoid uses the update hook rather than pre-receive to\n> allow it to allow/deny on a per-ref basis. One of the flaws of\n> the pre-receive hook \"API\" is it is an all-or-nothing proposition.\n> \n> So by using the \"older\" update hook update-paranoid can make its\n> decision on a per-ref basis and allow some refs to change in this\n> push but abort/deny others. I find that useful but not everyone\n> might.\n> \n> > AFAIK both update and pre-receive hooks are invoked also on fetch...\n> > but I might be mistaken.\n> \n> No, they are *not* invoked on fetch. Currently no hooks execute\n> during fetch; either on the server *or* on the client side of\n> the connection.\n> \n> -- \n> Shawn.\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n-- \nBruno Ribas - ribas@c3sl.ufpr.br\nhttp://web.inf.ufpr.br/ribas\nC3SL: http://www.c3sl.ufpr.br \n"},{"id":"64369","messageId":"20080103044552.GB24004@spearce.org","threadId":"11446","inReplyTo":"477C7459.3020402@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-01-03T04:45:52Z","receivedAt":"2008-01-03T04:45:52Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Gonzalo Garramuo wrote:\n> Shawn O. Pearce wrote:\n> >\n> >If you read the documentation carefully you will note that the\n> >pre-receive hook receives input on stdin; 1 line of data per ref\n> >that is being pushed with the old/new SHA-1 values and the ref\n> >name. The hook exits 0 to allow all changes to take place and\n> >can exit > 0 to abort and disallow all updates.\n> >\n> \n> Sure, but I cannot pass any sort of authentication to the script other \n> than rely on environment variables or system calls, as git will not \n> provide anything else.\n\nCorrect.\n \n> To do proper authentication on a file or directory basis, I have to mix \n> two things then:\n> \n> A user/group base authentication/login based likely on unix permissions \n> and ssh AND a pre-receive hook script that finds the user/group name and \n> then checks whether the user can change that particular file/directory.\n> \n> I hope the ref name is the (relative) path name to the file and not just \n> the file's basename.\n\nNo, the ref name is the name of the branch being modified. If there\nis only one branch in your repository its probably always going to\nbe the default name of \"refs/heads/master\".\n\nIf you want to know what files the user has changed you need to\ndiff the two SHA-1s (old against new) to come up with the names of\nthe files being changed; e.g.:\n\n\tgit diff-tree -r $old $new\n\nThe update-paranoid hook in contrib has support for doing this\nbuilt-in and can allow A/M/D type changes on specific file paths,\nentire directories, or any regex pattern that matches the above.\nI use this at day-job to prevent users from doing stupid things to\ndirectories they shouldn't be changing on particular branches.\n\n> To distinguish a bad commit due to tabs for example from an actual \n> permission trouble. I'm assuming that the stderr/stdout of git hooks is \n> redirected back to the client?\n\nYou need to diff the old against the new (or use rev-list to list\nall of the commits between old and new and then get the patch for\neach of those commits) to determine if the commit is \"bad\" or not.\nRemember that a single git-push can upload hundreds of commits in\none shot to the receiving repository.\n\nBut yes, both stdout and stderr of the hook are tied to the stderr\nof the client running git-push. So error messages produced by\nthe hook to explain why the push is being denied are visible to\nthe end-user who is executing git-push. Again, update-paranoid\nuses this to tell you if the \"committer\" line in commit objects is\ninvalid, or if you are changing a file you shouldn't be.\n \n> Even with all of that, it seems it is still not possible to limit pulls \n> to a certain directory only, right?\n\nNo. Git pretty much requires that when you have access to fetch/pull\na repository you have access to *all* of that repository. Limiting to\na subdirectory would actually require moving that entire subdirectory\ninto its own repository and using git-submodule instead to manage it.\n\n> Anyway, I think I more or less have the answer I (sadly) expected. \n> Git's authorization mechanism is pretty much a roll your own type thing. \n> I'll check out the python authorization script that Linus mentioned to \n> see if that alleviates setup troubles a bit.\n\nIts a distributed version control system. All peers are equal.\nMost security in Git is handled by only pulling from sources you\ntrust, and never allowing someone to push stuff into a repository\nyou own.\n\nAs such it also usually boils down to UNIX filesystem security; what\nI let you see is what you can see, what I firewall and hide from\nyou is what you cannot see. Quite simple when you think about it,\nbut then you are moving away from a centralized development model\nand going to a distributed one... which is what Git was built for.\n\n-- \nShawn.\n"},{"id":"64372","messageId":"20080103051931.GC24004@spearce.org","threadId":"11446","inReplyTo":"477C7BF8.2090406@advancedsl.com.ar","subject":"Re: Git and securing a repository","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-01-03T05:19:31Z","receivedAt":"2008-01-03T05:19:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Gonzalo Garramuo wrote:\n> Shawn O. Pearce wrote:\n> >\n> >Its a distributed version control system. All peers are equal.\n> >Most security in Git is handled by only pulling from sources you\n> >trust, and never allowing someone to push stuff into a repository\n> >you own.\n> >\n> \n> Regarding that... is there a way to control the umask of a git clone \n> independent of the actual umask of the user or directories inside the \n> repository? Ideally, on the server side?\n> \n> That is, for sensitive repositories, I would like \"git clone\" to always \n> clone that repository with 0700 permissions, so that the silly mistake \n> of cloning a sensitive repository into a public directory and forgetting \n> to restrict its permissions can be avoided completely.\n\nNo.\n\nFor a local clone (same UNIX system) you could probably easily\nmodify git-clone.sh to consult the config file of the source\nrepository to obtain recommended initial permissions, or just use\nthe source repository's directory permissions as the new clone's\ninitial permissions. But not everyone would want that behavior.\n\nFor a remote clone (different systems) the config file of the source\nrepository isn't easily available. So its not easily used to get\nthat setting. The git protocol would have to be extended to make\ntransfer of parts of the config file possible. We've talked about\nthis in the past but have never had a compelling application to\ncause patches to be submitted for it.\n\n-- \nShawn.\n"},{"id":"64368","messageId":"477C7459.3020402@advancedsl.com.ar","threadId":"11446","inReplyTo":"20080103035838.GA24004@spearce.org","subject":"Re: Git and securing a repository","fromName":"Gonzalo Garramuño","fromEmail":"ggarra@advancedsl.com.ar","sentAt":"2008-01-03T05:36:25Z","receivedAt":"2008-01-03T05:36:25Z","isPatch":false,"sender":{"key":"ggarra@advancedsl.com.ar","avatar":null},"body":"Shawn O. Pearce wrote:\n> \n> If you read the documentation carefully you will note that the\n> pre-receive hook receives input on stdin; 1 line of data per ref\n> that is being pushed with the old/new SHA-1 values and the ref\n> name. The hook exits 0 to allow all changes to take place and\n> can exit > 0 to abort and disallow all updates.\n> \n\nSure, but I cannot pass any sort of authentication to the script other \nthan rely on environment variables or system calls, as git will not \nprovide anything else.\n\nTo do proper authentication on a file or directory basis, I have to mix \ntwo things then:\n\nA user/group base authentication/login based likely on unix permissions \nand ssh AND a pre-receive hook script that finds the user/group name and \nthen checks whether the user can change that particular file/directory.\n\nI hope the ref name is the (relative) path name to the file and not just \nthe file's basename.\n\nIf so, I can see that most of what I want to do is possible. It is just \npretty far from being elegant or easy to set up.\n\nTo distinguish a bad commit due to tabs for example from an actual \npermission trouble. I'm assuming that the stderr/stdout of git hooks is \nredirected back to the client?\n\nEven with all of that, it seems it is still not possible to limit pulls \nto a certain directory only, right?\n\nAnyway, I think I more or less have the answer I (sadly) expected. \nGit's authorization mechanism is pretty much a roll your own type thing. \n I'll check out the python authorization script that Linus mentioned to \nsee if that alleviates setup troubles a bit.\n\n-- \nGonzalo Garramuño\nggarra@advancedsl.com.ar\n\nAMD4400 - ASUS48N-E\nGeForce7300GT\nXubuntu Gutsy\n"},{"id":"64371","messageId":"477C7BF8.2090406@advancedsl.com.ar","threadId":"11446","inReplyTo":"20080103044552.GB24004@spearce.org","subject":"Re: Git and securing a repository","fromName":"Gonzalo Garramuño","fromEmail":"ggarra@advancedsl.com.ar","sentAt":"2008-01-03T06:08:56Z","receivedAt":"2008-01-03T06:08:56Z","isPatch":false,"sender":{"key":"ggarra@advancedsl.com.ar","avatar":null},"body":"Shawn O. Pearce wrote:\n> \n> Its a distributed version control system. All peers are equal.\n> Most security in Git is handled by only pulling from sources you\n> trust, and never allowing someone to push stuff into a repository\n> you own.\n> \n\nRegarding that... is there a way to control the umask of a git clone \nindependent of the actual umask of the user or directories inside the \nrepository? Ideally, on the server side?\n\nThat is, for sensitive repositories, I would like \"git clone\" to always \nclone that repository with 0700 permissions, so that the silly mistake \nof cloning a sensitive repository into a public directory and forgetting \nto restrict its permissions can be avoided completely.\n\n\n-- \nGonzalo Garramuño\nggarra@advancedsl.com.ar\n\nAMD4400 - ASUS48N-E\nGeForce7300GT\nXubuntu Gutsy\n"},{"id":"64378","messageId":"200801031011.29050.jnareb@gmail.com","threadId":"11446","inReplyTo":"20080103035838.GA24004@spearce.org","subject":"Re: Git and securing a repository","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-03T09:11:24Z","receivedAt":"2008-01-03T09:11:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn O. Pearce wrote:\n> Jakub Narebski wrote:\n \n> > AFAIK both update and pre-receive hooks are invoked also on fetch...\n> > but I might be mistaken.\n> \n> No, they are *not* invoked on fetch. Currently no hooks execute\n> during fetch; either on the server *or* on the client side of\n> the connection.\n\nErrr... I think at least post-update hook (the one with \ngit-update-server-info by default) is invoked on fetch.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"64379","messageId":"7vzlvns11r.fsf@gitster.siamese.dyndns.org","threadId":"11446","inReplyTo":"200801031011.29050.jnareb@gmail.com","subject":"Re: Git and securing a repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-03T09:36:48Z","receivedAt":"2008-01-03T09:36:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Shawn O. Pearce wrote:\n>> Jakub Narebski wrote:\n> \n>> > AFAIK both update and pre-receive hooks are invoked also on fetch...\n>> > but I might be mistaken.\n>> \n>> No, they are *not* invoked on fetch. Currently no hooks execute\n>> during fetch; either on the server *or* on the client side of\n>> the connection.\n>\n> Errr... I think at least post-update hook (the one with \n> git-update-server-info by default) is invoked on fetch.\n\nPlease don't think then. Instead check your facts before\nposting to avoid wasting bandwidth and people's time. The\npost-update hook is run on the remote end when you push into it.\n\nI do not particularly like hooks that act after an operation is\ninitiated locally and act solely on local data. This is maybe\nbecause I still consider git tools building blocks suitable for\nhigher level scripting more than other people do.\n\nThere are five valid reasons you might want a hook to a git\noperation:\n\n (1) A hook that countermands the normal decision made by the\n underlying command. Examples of this class are the update\n hook and the pre-commit hook.\n\n (2) A hook that operates on data generated after the command\n starts to run. The ability to munge the commit log message\n by the commit-msg hook is an example.\n\n (3) A hook that operates on the remote end of the connection\n that you may not otherwise have access to other than over\n the git protocol. An example is the post-update hook.\n\n (4) A hook that runs under a lock that is acquired by the\n command for mutual exclusion. Currently there is no\n example, but if we allowed the update hook to modify the\n commit that was pushed through send-pack => receive-pack\n pair, which was discussed on the list a while ago, it would\n be a good example of this.\n\n (5) A hook that is run differently depending on the outcome of\n the command. The post-merge hook conditionally run by\n git-pull is an example of this (it is not even run if no\n merge takes place). Another example is the post-checkout\n hook that gets information that is otherwise harder to get\n (namely, if it was a branch checkout or file checkout --\n you can figure it out by examining the command line but\n that already is part of the processing git-checkout does\n anyway, so no need to force duplicating that code in the\n userland).\n\nYou cannot do an equivalent operation from outside the git\ncommand for the above classes of operations. You need hooks\nfor them.\n\nOn the other hand, if you want to always cause an action after\nrunning a git opeation locally, you do not have to have a hook.\nYou can just run them yourself, or have \"git myfetch\" wrapper\nthat does whatever you want after running \"git fetch\". Only\nwhen the combination of the underlying command and something\nelse is widely useful, _and_ that something else needs\nflexibility, a hook is warranted (if that something else is\nalways the same thing, it is better to fold that into the\nunderlying command).\n"}]}