On 28/02/13 09:39, Daniel Pocock wrote: > Has anybody had experience controlling access to git repositories, for > example, to give users access but prevent some of the following > dangerous operations?
Do you consider this to be a strong security measure against malicious changes, or a weak safety measure against accidents? As a security measure, it's basically not going to work as long as users have unrestricted Unix write access to the git repository: anything you set up can be circumvented (at worst, by "rm -rf all subdirectories and replace them"). I suspect that only a system like Gitorious or Gerrit, where the repository is owned by a dedicated uid and individual users don't have +w, can give you that. As a safety measure against accidents, how far do you need/want to go? As Tollef and Andrey mentioned, denying non-fast-forward pushes protects you from "most" accidents; it can be circumvented by a sufficiently determined committer, but perhaps "don't do that, then". If you look at it from the appropriate angle, the combination of ftp.d.o and snapshot.d.o (particularly source packages) is a big, inefficient VCS, with a rather wider user-base than Alioth - what the maintainer says the git history of package "foo" is seems relatively unimportant when compared with what its upload history looks like. All DDs have the ability to "commit" wide-ranging changes to that "VCS", and we mostly regulate that by social conventions for what can and can't be in an NMU or a "team upload", discouraging hostile NMUs and hijacking, etc., rather than by applying chmod. See also <http://joeyh.name/blog/entry/ending_the_tyranny_of_unix_permissions/> for an interesting viewpoint on this. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512f4a5b.7060...@debian.org
