2009-11-17 4 views
1

mercurial-server gère la base de données utilisateur sous le dossier keys. Les utilisateurs et les groupes sont représentés par des fichiers et des dossiers.Comment utilisez-vous AclExtension et mercurial-server/hg-ssh?

AclExtension repose sur le groupe d'utilisateurs Linux via ssh.

ils ne semblent pas correspondre. ou ai-je oublié quelque chose?

J'ai réussi à faire du mercurial-server. mais juste ne vois pas comment intégrer AclExtension avec cela, donc je peux avoir un contrôle d'accès plus fin.

Répondre

3

Malheureusement, l'extension AclExtension permet d'accéder aux noms d'utilisateur. Si vous créez des comptes d'utilisateur UNIX séparés pour chaque utilisation avec hg-ssh, vous avez tout ce dont vous avez besoin, mais si tous vos utilisateurs ssh utilisent le même compte utilisateur Unix alors l'extension Acl ne fonctionnera pas pour vous.

... À moins

Je ne regarde dans le tout fichier acl.py et il semble que il utilise le getUser du module getpass.py qui vérifie l'environnement pour le nom d'utilisateur en utilisant ce code:

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

il pourrait être possible de faux qui en réglant une variable d'environnement dans les authorized_keys de l'utilisateur hg-ssh fichier comme ceci:

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

où alors vous pourriez mettre fakeusername dans les règles ACL, et pourrait avoir un fakeusername différent pour chaque clé, tous s'exécutant sous le même compte UNIX.

BTW: Tout le monde semble juste utiliser hg-ssh seul, je ne vois plus l'application mercurial-server (non-officielle) utilisée plus.

1

L'astuce de l'environnement ne semble pas fonctionner sur ma boîte Solaris; Ma solution était de passer le fakeusername comme paramètre à hg-ssh et d'avoir os.environ ['LOGNAME'] pour que getpass le voie.

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