> > 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. > 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? > 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) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html