Re: Git and securing a repository

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 2, 2008, 16:18 UTC
Message-ID: <alpine.LNX.1.00.0801021058030.13593@iabervon.org>
In-Reply-To: <477B39B5.5010107@advancedsl.com.ar>

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

Show 12 quoted lines

> 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*