Question

我说办公室我们应该转移到Git。因为我们刚刚开始，所以我使用nginx在其前面使用普通git和https设置了一个git服务器。我们不使用gitlab或类似的东西 - 现在。

我得到的一个问题是，是否可以限制对新同事的特定分支（特别是主）的访问。它过去会给我们带来很多麻烦： - ）

在我寻找解决方案期间，我发现gitolite非常有前途，所以我试了一下并进行了设置。我得到了git up并经历了gitolite，所以我开始深入研究规则。

然而，我无法让他们正确。似乎gitolite忽略了the second check

我的gitlolite-admin/conf/gitolite.conf看起来像这样（我有一个更复杂的但是在调试时我把它剥离到最低限度）

@starters   =   auric

# project groups
@protected  =   master$

repo gitolite-admin
    RW+     =   admin

repo testing
    RW+     =   @all

repo playground
    R                =   @starters       # allow read from protected
    -   @protected   =   @starters       # deny anything else
    RW+              =   @starters       # allow everything on other branches

在文档中指定您可以trace the access control decision。

gitolite access -s playground auric的输出是

拉取访问权限

$ gitolite access -s playground auric R master
legend:
    d => skipped deny rule due to ref unknown or 'any',
    r => skipped due to refex not matching,
    p => skipped due to perm (W, +, etc) not matching,
    D => explicitly denied,
    A => explicitly allowed,
    F => denied due to fallthru (no rules matched)

  A        gitolite.conf:14         R                =   @starters       # allow read from protected

refs/.*

推送访问

$ gitolite access -s playground auric W master

  p        gitolite.conf:14         R                =   @starters       # allow read from protected
  D        gitolite.conf:15         -   @protected   =   @starters       # deny anything else

W refs/heads/master playground auric DENIED by refs/heads/master$

快退推送访问

$ gitolite access -s playground auric + master
  p        gitolite.conf:14         R                =   @starters       # allow read from protected
  D        gitolite.conf:15         -   @protected   =   @starters       # deny anything else

+ refs/heads/master playground bert.van.dooren DENIED by refs/heads/master$

在另一个分支上推送访问

$ gitolite access -s playground bert.van.dooren W anyotherbranch
  p        gitolite.conf:14         R                =   @starters       # allow read from protected
  r        gitolite.conf:15         -   @protected   =   @starters       # deny anything else
  A        gitolite.conf:16         RW+              =   @starters       # allow everything on other branches

refs/.*

正是我所期望的那样。事实上，这是我在~/.gitolite/logs执行这些命令后看到的（我在这里删除了日期）：

32205   cli     gitolite        access  -s      playground      auric W       master
32205           system,/home/git/gitolite/src/commands/access,-s,playground,auric,W,master
32205           system() failed,/home/git/gitolite/src/commands/access,-s,playground,auric,W,master,-> 256

然而，当我实际开始使用git并通过httpd执行推送（甚至是倒带推送）时，所有命令都是允许的，我在日志中看到了这一点

32196   http    ARGV=auric    SOC=git-receive-pack 'playground.git'   FROM=10.0.13.105
32196   pre_git playground      auric W       any     refs/.*
32196           system,git,http-backend
32196   END

好像只检查1，但检查2从未到来。

我在这里想念什么？

编辑我正在使用gitolite3。我知道一些答案是关于添加规则R master = @starters但是然后gitolite给我警告说该规则没有任何意义。它被忽略了。

Answer 1

The gitolite dev notes提到pre-git步骤是第一次访问检查成功时（即在调用git-upload-pack或git-receive-pack之前）出现的日志行。

但是，update步骤未在日志中列出：它是第二次访问检查成功时显示的步骤（即，当update挂钩决定允许推送时）。< / p>

这意味着该回购的update hook可能没有正确到位（每个repo挂钩文件夹中的符号链接到gitolite更新脚本）。
gitolite setup应该照顾这些链接。

实际上，OP Auric条评论below：

update挂钩已经到位且我确实使用了gitolite setup，我是通过其他用户完成的。

由于我无法将fcgiwrap配置为在其他用户下运行，因此我必须确保gitolite安装在用户git下，但可以使用用户{{1}执行}。
  为此，我使用了bindfs   但是，由于我在用户www-data下运行了gitolite setup，git挂钩符号链接到update而不是/home/git/.gitolite/...
  现在，我使用/opt/gitolite/.gitolite/...作为/opt/gitolite重新设置了设置，以便符号链接正确。

当通过httpd访问时，Gitolite不遵守规则

1 个答案: