Re: Repository Security

From: Andre Masella <andre@masella.no-ip.org>
Date: Jan 23, 2007, 13:23 UTC
Message-ID: <200701230823.16021.andre@masella.no-ip.org>
In-Reply-To: <20070122205304.GB29739@spearce.org>

Show 6 quoted lines

> > As I understand it, none of the repository backends allow any per-user
> > per-branch access control. SSH and HTTP come the closest with the right
> > hooks, but since the repository is writeable by those users, there is
> > little to stop them from changing the repository directly.
>
> Yes.  But hooks cannot be run in the HTTP case, can they?

Err...yes. I don't know what I was thinking when I wrote that.

> However in the HTTP case we use WebDAV to update the remote 
> server, which means security controls in the WebDAV server are
> probably sufficient to prevent unauthorized object upload or ref updates.

Apache has fairly limited authorization when it comes to WebDAV. I can authenticate users, but then there is no easy way to determine if they should be allowed to modify a particular file and the underlying file system can't help because all the users are mapped to a single one. Controlling access to directories would require creating .htaccess files everywhere with a list of allowed users.

Show 6 quoted lines

> In the SSH case I fixed it by installing git-receive-pack setuid
> to the repository owner.  I locally patched receive-pack.c so it
> disables hook execution if that particular hook isn't owned by the
> repository user (to prevent rogue users from running arbitrary things
> as the repository owner).  This way nobody can change anything in
> a repository except through git-receive-pack.

That is very clever.

> Rather draconian.  But in a corporate world with some strict legal
> requirements placed upon you by your contracts with your customers
> sometimes you do have to verify that Bob really is Bob, or at least
> knows Bob's password.

Even without the legal requirements, management may resist a system where a developer from one project can view, let alone modify, another project.

> > I could also make the HTTP less dumb, if I had a better idea what that
> > might involve. 
> The HTTP push client is dumb because it needs to send loose objects
> to the remote repository.

Okay. And HTTP is the only dumb protocol right now?

> A "smart" plugin to Apache is unnecessary I think.  A CGI which
> splits the main() method of git-receive-pack into two halves (one
> to write_head_info, the other to do the rest of the work) is all
> that is required here to make HTTP push smart.

I see. I wonder about building this into gitweb. Adding a little check of the User-Agent can make it decide if it is going to display pretty things or allow repository access.

> Then have the HTTP client make one GET request to obtain the head info,
> then a POST request to upload the pack to git-receive-pack.

This would break exisiting HTTP repositories though. Perhaps it should get a different name.

In recieve-pack, are the commands read in read_head_info (which would be the POST request) all unidirectional?

Show 5 quoted lines

> Since the hooks are then running as the web server user, and inherit
> the entire HTTP environment, you can do authentication in the web
> server but do authorization from within the hook, where you have
> much finer control to inspect what is occurring.  And only the web
> server needs to have write access to the repository.

All of which is fairly easy to do.

-- 
--Andre Masella (andre at masella.no-ip.org)