1

mercurial-server は、keys フォルダーの下でユーザー データベースを管理します。ユーザーとグループは、ファイルとフォルダーで表されます。

AclExtension は、ssh を介して Linux ユーザー グループに依存しています。

それらは一致していないようです。または私は何かを逃しましたか？

mercurial-server を機能させることができました。しかし、AclExtension を統合する方法がわからないので、よりきめ細かいアクセス制御を行うことができます。

4

2 に答える 2

3

残念ながら、AclExtension はユーザー名からアクセスをキーにしています。hg-ssh を使用してそれぞれに個別の UNIX ユーザー アカウントを作成している場合、必要なものはすべて揃っていますが、すべての ssh ユーザーが同じ Unix ユーザー アカウントを使用している場合、AclExtension は機能しません。

そうでもなければ...

acl.py ファイルを調べたところ、次のコードを使用してユーザー名の環境をチェックする getpass.py モジュールの getuser を使用しているようです。

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

したがって、次のように hg-ssh ユーザーのauthorized_keysファイルに環境変数を設定することで、それを偽造することが可能かもしれません:

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

次に、偽のユーザー名を ACL ルールに配置し、キーごとに異なる偽のユーザー名を設定して、すべて同じ UNIX アカウントで実行することができます。

ところで: 誰もが hg-ssh を単独で使用しているようですが、(非公式の) mercurial-server アプリが使用されていることはもうありません。

于 2009-11-17T05:54:30.943 に答える
1

Solarisボックスでは、環境トリックが機能していないようです。私の解決策は、fakeusernameをパラメーターとしてhg-sshに渡し、getpassがそれを認識できるようにos.environ['LOGNAME']を設定することでした。

command="hg-ssh fakeusername" ssh-dss ...
于 2009-12-06T17:58:52.680 に答える