限制 Mercurial 存储库访问

发布于 2025-01-01 03:25:19 字数 349 浏览 1 评论 0原文

我有一个使用 mercurial-server 的 Mercurial 服务器。我在 hgadmin 存储库中编辑了 access.conf,如下所示:

deny repo=a/b
read user=x/**
read user=y/**

write repo=a/b user=x/abc
write repo=a/b user=y/z

但用户 z 仍然无法访问此存储库。有什么想法吗?

I have a Mercurial server using mercurial-server. I edited access.conf in hgadmin repo as follows:

deny repo=a/b
read user=x/**
read user=y/**

write repo=a/b user=x/abc
write repo=a/b user=y/z

But user z still can't access this repo. Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

雪若未夕 2025-01-08 03:25:19

文档提到

user=globpattern:用户密钥的路径

因此z的密钥的路径可能是错误的,或者存储库的路径已关闭。

在考虑请求时,mercurial-server 会逐步执行 /etc/mercurial-server/access.conf 中的所有规则,然后执行 access.conf 中的所有规则在 hgadmin 中,查找与每个条件匹配的规则。
第一个匹配决定是否允许请求;如果两个文件都不匹配,则请求将被拒绝。

其他可能性:可能首先找到拒绝规则(适用于用户z)。

The documentation mentions:

user=globpattern: path to the user's key

So the path of z's key might be wrong, or the path of the repo is off.

When considering a request, mercurial-server steps through all the rules in /etc/mercurial-server/access.conf and then all the rules in access.conf in hgadmin, looking for a rule which matches on every condition.
The first match determines whether the request will be allowed; if there is no match in either file, the request will be denied.

Other possibility: Maybe a deny rule (applicable for user z) is found first.

随风而去 2025-01-08 03:25:19

应用第一个匹配规则。在这种情况下,拒绝规则是第一个,因此它将首先匹配;无论其他规则遵循什么规则,任何用户都不会被授予访问 repo a/b 的权限。

尝试将两个写入规则放置在拒绝规则之上。

另请注意,/etc/mercurial-server/access.conf 中的任何规则在逻辑上都将位于这些规则之前。

The first matching rule applies. In this instance the deny rule is first, so it will match first; no user will be given access to repo a/b no matter what other rules follow this one.

Try placing the two write rules above the deny rule.

Note also that any rules in /etc/mercurial-server/access.conf will logically precede these rules.

绝不放开 2025-01-08 03:25:19

您可能需要了解 Mercurial 服务器的另一项特殊性。您不能在 hgadmin 的 keys/ 中多次重复密钥。因为在服务器端,这些密钥被编译到 /var/lib/mercurial-server/.ssh/authorized_keys 中。因此,如果您在keys/中的不同密钥文件中指定相同的密钥,那么当hg执行ssh时,它将使用authorixed_keys中密钥的第一次出现,并且可能仅引用第一个存储库并禁用对引用另一个文件的另一个存储库的访问(但具有相同的存储库)钥匙)

There is one more especiality about mercurial server that you may need to know. That you can not duplicate keys several times in keys/ of hgadmin. Because on server side those keys are compiled into /var/lib/mercurial-server/.ssh/authorized_keys. So if you specify same key in different key files in keys/ then when hg do ssh it will use first occurence of the key in authorixed_keys and probbaly refer to first only repo and disable access to another repos which refer to another file (but with same key)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文