拒绝写入访问特定的分支gitolite

Question

有我我gitolite的conf的一部分：

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

所以，我想：

1. teamleads有myproject的回购
2. 开发者的完全控制仅具有“生产”分支的READ权限，并且完全访问任何其他分支
3. 部署用户只具有对任何分支的读权限

就目前而言，这样的团队成员和开发人员可以推到生产部门。我用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） SSH -vvv gitolite3@gitolite.myproject.com信息 我有

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）

ssh-keygen -y 

我已经完成了ssh keypaire与ss H-keyg根。顺便说一句，情况是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

不是真的一个明确的答案，但我会尽力让你去到正确的方向＆hellip;

首先，考虑分组您的用户制定规则更容易维护，就像这样：

@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如何通过您的规则集。

首先，它看到这套规则：

1. RW+ = @teamleads
2. - = @devs
3. R production = @devs
4. RW+ = @devs
5. R = deploy

这届恩丢弃那些不适用于用户请求的操作，并结束了：

1. - = @devs 必须否认请求的操作（但没有）。
2. R production = @devs 不考虑操作不是W。
3. RW+ = @devs 应该允许推（和强制推送）。

正如你所看到的，（1）必须阻止推动，但它没有。

因此，我认为这是你有一些规则早于该项目的特殊条目优先。

无论哪种情况，您都可以在服务器上使用gitolite程序本身peer at how gitolite processes your rules。

我通常做到这一点使用su先“成为”用户gitolite用做它的工作，就像在

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

我不知道，但我想你需要为这个gitolite V3到工作。

---

更新＃0相同编号的更新答案如下。

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

请试试这个：

1. 运行

   ssh -vvv gitolite3@gitolite.myproject.com info 
   

   看什么身份被使用（密钥）文件。

   此命令（info）单独应该没问题搞清楚哪些用户gitolite认为你的SSH密钥授权你为：在其信息输出的第二行gitolite打印此。

   其他步骤因此是可选的，但我已经包括它们的完整性—可能会更清楚地说明gitolite如何将密钥映射到其虚拟用户。

2. 提取并打印其公共部分使用

   ssh-keygen -y 
   

3. 转到gitolite的配置，并设法找到该文件.ssh/authorized_keys有在公共部分;查看该密钥映射到的用户。

   这个文件基本上是一组 被组织这样的线—一个每gitolite的虚拟用户—的：

   command="/usr/share/gitolite3/gitolite-shell USER",OPTS KEY_TYPE PUBKEY 
   

   ，这样的类型KEY_TYPE与公共部分PUBKEY SSH密钥被映射到一个gitolite用户USER并被强制使用指定的命令。