Re: Git and securing a repository

[Daniel Barkalow <barkalow@iabervon.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2124 bytes --]

On Wed, 2 Jan 2008, Gonzalo Garramuño wrote:

> I've been using git for some time and love it.  For open source projects
> there's clearly nothing currently better.
> 
> However, I am now using git for proprietary elements, which in the future I
> may need or want to partially restrict access to.  The idea being that at my
> company some (junior) developers should not be given access to some elements.
> That means either that some full git repository should be password protected
> or even portions of the same repository.
> 
> Another desirable way to protect elements might be only giving clone/pull
> access to a repository (or portion of it) but not permissions to push in
> changes.

In order to understand the security model, you have to remember that git 
is designed as a distributed system. Authorization is fundamentally not at 
a project level, but rather at a repository level, and clones are all 
different repositories. This makes portability of the mechanism less 
important, because a particular set of authorization rules only applies to 
a particular repository, which is going to be on some single system.

For that matter, git doesn't run with any special privileges in general; 
if a user can affect the repository with git operations, that user can 
affect the repository by hand, so git-specific rules aren't helpful. 
(Although I suppose it would be theoretically useful to make git-shell, 
the shell that only runs git programs, able to apply restrictions, since 
it is used in a context where the user doesn't have any other access to 
the filesystem.)

For read access restrictions, you want to use submodules (or entirely 
separate projects); git is fundamentally unhappy running with less than 
all of the project accessible, except for when a project references 
another project with submodules. And, of course, if the code base is such 
that users can do useful work without any access to some of the files, 
those files must be optional and somewhat separate from the necessary 
portions, and it makes sense to handle them separately anyway.

	-Daniel
*This .sig left intentionally blank*