Question

我的gitolite conf有我的一部分：

repo myproject
    RW+             = teamlead1 teamlead2
    -               = dev1 dev2 dev3
    R   production  = dev1 dev2 dev3
    RW+             = dev1 dev2 dev3
    R               = deploy

所以，我想：

teamleads可以完全控制myproject repo
开发者只有“生产”分支的READ权限，以及对任何其他分支的完全访问权
将用户部署为仅对任何分支机构具有READ权限

目前有这样的conf teamleads和开发者可以推送到生产分支。我用gitolite2和gitolite3版本测试它没有成功。

Update0 即可。我很抱歉，我想念DENY系列中的“生产”分支规范。

所以，我对我的gitolite.conf做了一点修改

repo myproject
    RW+             = teamlead1 teamlead2
    -  production   = dev1 dev2 dev3
    RW+             = dev1 dev2 dev3
    R               = deploy

所以，这是gitolite访问检查的输出（感谢 kostix ）：

gitolite3@gitolite:~$ bin/gitolite access -s myproject dev1 W production
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)

  D        gitolite.conf:125        -   refs/heads/production   = dev1 dev2 dev3

W refs/heads/production myproject dev1 DENIED by refs/heads/production

对于READ访问，我有：

  D        gitolite.conf:125        -   refs/heads/production   = dev1 dev2 dev3

R refs/heads/production myproject dev1 DENIED by refs/heads/production

但实际上我可以克隆并从远程服务器推送到生产分支。

$ git push
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 229 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
To gitolite3@gitolite.myproject.com:myproject.git
   1527c05..8485ede  production -> production

UPDATE1

1）for ssh -vvv gitolite3@gitolite.myproject.com info 我有

hello dev1, this is gitolite3@gitolite running gitolite3 v3.6.1-6-gdc8b590 on git 2.0.4

 R W    deploy
 R W    deploy_test
 R W    myproject

2）for

ssh-keygen -y

我已经用ssh-keyg-gen制作了ssh keypaire。顺便说一句，dev2和dev3等的情况是一样的 3）我只有一个字符串匹配“dev1”：

command="/srv/gitolite3/bin/gitolite-shell dev1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nz.....

Answer 1

不是一个明确的答案，但我会尽力让你走向正确的方向......

首先，考虑将用户分组以使规则更易于维护，如下所示：

@teamleads = teamlead1 teamlead2
@devs = dev1 dev2 dev3

repo myproject
    RW+             = @teamleads
    -               = @devs
    R   production  = @devs
    RW+             = @devs
    R               = deploy

接下来要考虑的是如何 gitolite检查访问权限。这是解释here - 见右图。

要理解的一些事情：

获取（因此克隆）是R操作。
推送是W操作（或W+，如果强制）。
gitolite应用从配置中收集的规则，直到它们中的一些匹配为止。

作为推论，给定规则中的R不适用于推送，并且给定规则中的W不适用于提取。

因此，当开发人员推动分支机构“生产”时，让我们看看gitolite如何通过您的规则集。

首先，它看到了这套规则：

RW+ = @teamleads
- = @devs
R production = @devs
RW+ = @devs
R = deploy

然后丢弃那些不适用于请求操作的用户并最终得到：

- = @devs 必须拒绝所请求的操作（但它没有）。
R production = @devs 不认为该操作不是W。
RW+ = @devs 应该允许推（和强制推）。

正如你所看到的，（1）必须阻止推动，但事实并非如此。

因此，我对此的看法是，你有一些规则早于该项目的特定条目优先。

在任何一种情况下，您都可以peer at how gitolite processes your rules在服务器上使用gitolite程序。

我通常使用su执行此操作，首先“成为”用户gitolite用于执行其工作的内容，例如

# su git -l -s /bin/sh
$ gitolite access -s myproject dev1 W refs/heads/production

我不确定，但我想你需要gitolite v3来实现这个目的。

更新＃0 ，对答案进行相同编号的更新。

请您仔细检查在服务器上进行身份验证时使用的密钥SSH是否确实映射到了dev1 gitolite的用户，而不是其他人？

请试试这个：

运行
```
ssh -vvv gitolite3@gitolite.myproject.com info
```
查看使用了哪个身份（密钥）文件。

单独使用此命令（info）可以确定用户gitolite认为您的SSH密钥授权您的用户：gitolite在其信息输出的第二行打印出来。< / p>
其他步骤因此是可选的，但我已将它们包含在内以便完整 - 可能会更清楚地说明gitolite如何将键映射到其虚拟用户。
使用
提取并打印其公共部分
```
ssh-keygen -y
```
转到gitolite的配置并尝试在那里的.ssh/authorized_keys文件中找到该公共部分;看看这个键映射到的用户。

这个文件基本上是一组线 - 每个gitolite的虚拟用户一个 - 这个像这样组织：
```
command="/usr/share/gitolite3/gitolite-shell USER",OPTS KEY_TYPE PUBKEY
```
以便将具有公共部分KEY_TYPE的{{1}}类型的SSH密钥映射到gitolite用户PUBKEY，并强制使用指定的命令。
< / LI>

拒绝WRITE访问gitolite中的特定分支

1 个答案: