Gonzalo Garramuo <ggarra@xxxxxxxxxxxxxxxxx> wrote: > Shawn O. Pearce wrote: > > > >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. > > > > Sure, but I cannot pass any sort of authentication to the script other > than rely on environment variables or system calls, as git will not > provide anything else. Correct. > To do proper authentication on a file or directory basis, I have to mix > two things then: > > A user/group base authentication/login based likely on unix permissions > and ssh AND a pre-receive hook script that finds the user/group name and > then checks whether the user can change that particular file/directory. > > I hope the ref name is the (relative) path name to the file and not just > the file's basename. No, the ref name is the name of the branch being modified. If there is only one branch in your repository its probably always going to be the default name of "refs/heads/master". If you want to know what files the user has changed you need to diff the two SHA-1s (old against new) to come up with the names of the files being changed; e.g.: git diff-tree -r $old $new The update-paranoid hook in contrib has support for doing this built-in and can allow A/M/D type changes on specific file paths, entire directories, or any regex pattern that matches the above. I use this at day-job to prevent users from doing stupid things to directories they shouldn't be changing on particular branches. > To distinguish a bad commit due to tabs for example from an actual > permission trouble. I'm assuming that the stderr/stdout of git hooks is > redirected back to the client? You need to diff the old against the new (or use rev-list to list all of the commits between old and new and then get the patch for each of those commits) to determine if the commit is "bad" or not. Remember that a single git-push can upload hundreds of commits in one shot to the receiving repository. But yes, both stdout and stderr of the hook are tied to the stderr of the client running git-push. So error messages produced by the hook to explain why the push is being denied are visible to the end-user who is executing git-push. Again, update-paranoid uses this to tell you if the "committer" line in commit objects is invalid, or if you are changing a file you shouldn't be. > Even with all of that, it seems it is still not possible to limit pulls > to a certain directory only, right? No. Git pretty much requires that when you have access to fetch/pull a repository you have access to *all* of that repository. Limiting to a subdirectory would actually require moving that entire subdirectory into its own repository and using git-submodule instead to manage it. > Anyway, I think I more or less have the answer I (sadly) expected. > Git's authorization mechanism is pretty much a roll your own type thing. > I'll check out the python authorization script that Linus mentioned to > see if that alleviates setup troubles a bit. Its a distributed version control system. All peers are equal. Most security in Git is handled by only pulling from sources you trust, and never allowing someone to push stuff into a repository you own. As such it also usually boils down to UNIX filesystem security; what I let you see is what you can see, what I firewall and hide from you is what you cannot see. Quite simple when you think about it, but then you are moving away from a centralized development model and going to a distributed one... which is what Git was built for. -- 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
