Skip to content

Is there a ACL system for "all" revision control systems?

Once upon a time a company started using distributed version control, and setup several project repositories using darcs.

Over time people became more sane and new projects were created in mercurial.

Later still Git became available, and was used by a few of the brave.

Sadly each of these projects is hosted on the same host, and in the home directory of the same user. This means these two commands work:

hg clone ssh://projects@dev.host/foo

git clone ssh://projects@dev.host/bar

I'm now wanting to setup per-repository ACLs and have hit a problem...

There are several git-wrappers such as gitolite and gitosis. There is also the excellent hg-gateway and mercurial-server for dealing with mercurial.

However I've yet to find a wrapper which will handle both git & mercurial repositories, under the same UID. (+ Darcs too, of course).

So my question - is there such a beast out there, or do we need to write it? I expect such a thing would be useful for many people, so I'm surprised I've not yet found it.

Comments On This Entry

  1. [gravitar] bamanzi

    what about rhodecode?

  2. [author] Steve Kemp

    Never heard of it, but I don't think it is what I'm looking for. We already have Redmine for hosting the projects, hosting wikis, documentation, and browsing the code, etc.

    What I'm specifically looking for is a wrapper that will maintain ACLs when checking out a repository via SSH. So we can say something like:


    • All staff can access all repositories.
    • Contractor bob can checkout and commit to project foo only.
    • Contractor kate can checkout project foo, read-only, but have full access to project bar.

  3. [gravitar] Andrew Shadura

    I think RhodeCode is exactly what you need, but it would require you to use https, I guess.

    I'm working on packaging it for Debian, by the way.

  4. [author] Steve Kemp

    I realized, later, that it would work if we were willing to switch to HTTP, but that is probably a step too far at the moment - because we're happy with redmine.


  5. [gravitar] Anonymous

    The freedesktop.org folks have a simple C program that acts like git-shell, but for many different commands. Theirs just handles git, svn, and a couple other things, but extending it to cover darcs and hg should prove trivial. That gives you the limited SSH shell you need. Then just use normal Linux accounts and permissions to control access to the repositories themselves.

  6. [gravitar] Elessar

    I was never really fond of virtual hosting or virtual users, so if I were you I would simply create one Unix account on the server for each user, doing what it takes to restrict them to doing git or hg push. With that, the ACL system you look for already exists: Unix ACLs. Or simpler than that: Unix groups, one per project.

  7. [author] Steve Kemp

    The downside with renaming things, or moving to one user per-project, is that we'd have to make considerable updates:

    • Hudson/Jenkins checkout paths.
    • Per-Host checkouts of firewalls, etc.

    It could be done, but given that the current solution works - albeit without any restrictions on users - it seems like it should be possible. The gitosis/hg-gateway would be perfect if we were using only a simple DVCS system.

    In the absence of any good tool suggestions it seems like we'll have to write our own.

  8. [gravitar] Chow Loong Jin

    gitolite works by using .ssh/authorized_keys and force-command, then interpreting $SSH_ORIGINAL_COMMAND to figure out what the client wanted to do.

    I don't know how hg's stuff works over SSH, but it's quite likely that you could just write a small wrapper for use with force-command that checks if $SSH_ORIGINAL_COMMAND starts with git or hg, and calling the appropriate tool.

  9. [gravitar] Alex

    Possibly convert over to Git as a common repository format, and then use tools (http://hg-git.github.com/) to make existing systems work with that?

  10. [gravitar] Jan Hudec

    I don't think there is any, but it should be easy to extend either gitosis, gitolite or hg-gateweay to support the other system too. You only need to teach it to understand the `SSH_COMMAND` sent by the other system.

  11. [gravitar] Elessar

    Steve, I do not understand your reply. There is no need to defined one Unix user per project, just one Unix user per user, and one group per project. After that, it is just usual Unix group membership management. And no need to rename whatever, you can still put your repositories wherever you like.

  12. [author] Steve Kemp

    Elessar - I think I misunderstood your idea initially, thanks. Though I'd prefer not to add more users to the system - the whole idea of having all projects stored beneath ~projects was that we'd not need to create logins/accounts for other users. If I understand your suggestion fully I think you're suggesting we add unix users for each users, and then change the projects to be owned by projects:group, where the committers would be added to the group.

    Everybody else: Yes, using ~/.ssh/authorized_keys is the route we expect to go down. The choice seems to be extend one of the existing wrappers to support the extra revision control systems we use, or write our own.

    I think extending would be simple for most, but it comes down to whether the projects would accept being revision-control-agnostic or not. I'll look over the code and see if I can persuade the author(s) that it would be a sane choice.

    Alex: I think mass-converting repositories wouldn't be something I'd enjoy doing. It's probably painless, and probably safe, but many projects are essentially mothballed and I'd rather not get into changing/updating them.