tags:

views:

73

answers:

2

mercurial-server manages user database under keys folder. Users and groups are represented by files and folders.

AclExtension relies on linux user group through ssh.

they don't seem to match. or did I miss something?

I have managed to make mercurial-server work. but just don't see how to integrate AclExtension with it so I may have finer grained access control.

+3  A: 

Unfortunately, the AclExtension does key its access off of usernames. If you are creating separate UNIX user accounts for each using with hg-ssh you've got everything you need, but if all of your ssh users are using the same Unix user account then the AclExtension isn't going to work for you.

Unless...

I did just look into the acl.py file and it looks like it uses the getpass.py module's getuser which checks the environment for the user name using this code:

for name in ('LOGNAME', 'USER', 'LNAME', 'USERNAME'):
    user = os.environ.get(name)
    if user:
        return user

so it might be possible to fake that out by setting an environment variable in the hg-ssh user's authorized_keys file like this:

command="hg-ssh path/to/repo" environment="LOGNAME=fakeusername" ssh-dss ...

where then you could put fakeusername in ACL rules, and could have a different fakeusername for each key, all running under the same UNIX account.

BTW: Everyone seems to just use hg-ssh alone, I never see the (non-official) mercurial-server app used anymore.

Ry4an
+1  A: 

The environment trick doesn't seem to work on my Solaris box; my solution was to pass in the fakeusername as a parameter to hg-ssh and have that set os.environ['LOGNAME'] so that getpass sees it.

command="hg-ssh fakeusername" ssh-dss ...
Wez Furlong