Re: git dangerous operations on alioth
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
Reply to: