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

这是我的gitolite配置的一部分：

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

所以，我想：

团队领导完全控制myproject回购

开发人员只能读取“生产”分支的perm，并且可以完全访问任何其他分支

将用户部署为仅对任何分支具有读取权限

目前，有了这样的配置，团队领导和开发人员可以推进到生产部门。我用gitolite2和gitolite3版本测试了它，但没有成功

更新0。 真的很抱歉，我错过了生产线中的“生产”分支规范

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

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

下面是gitolite访问检查的输出（多亏了kostix）：

对于读访问，我有：

  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

更新1

1） 为了 ssh-vvvgitolite3@gitolite.myproject.com信息 我有

2） 为了

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

---

这不是一个确定的答案，但我会努力让你进入正确的方向

首先，考虑将用户分组，使规则更加可维护，如：

@teamleads = teamlead1 teamlead2
@devs = dev1 dev2 dev3

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

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

下一个要考虑的事情是GITORE如何检查访问。这是解释-见右图

有几件事需要了解：

• 获取（以及克隆）是

  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）一定阻止了推，但它没有

因此，我对这一点的理解是，对于优先的项目，在这个特定条目之前，您有一些规则

在这两种情况下，您都可以在服务器上使用

gitolite

程序本身

我通常使用

su

首先“成为”gitolite用来完成工作的用户，如

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

我不确定，但我想你需要GitoliteV3才能工作

---

更新#0在对答案进行相同编号的更新之后

能否请您再次检查在服务器上进行身份验证时使用的SSH密钥是否确实映射到

dev1

gitolite的用户，而不是其他用户

请试试这个：

跑

ssh -vvv gitolite3@gitolite.myproject.com info

查看所使用的标识（密钥）文件

仅此命令（

info

）就可以确定用户gitolite认为您的SSH密钥授权给您什么：gitolite在其信息输出的第二行打印此命令

因此，其他步骤是可选的，但为了完整起见，我将其包括在内，以便更清楚地了解gitolite如何将密钥映射到其虚拟用户

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

ssh-keygen -y

转到gitolite的配置，并尝试在那里的文件

.ssh/authorized_keys

中找到该公共部分；查看此密钥映射到的用户

该文件基本上是一组行，每个gitolite的虚拟用户一行 组织方式如下：

@teamleads = teamlead1 teamlead2
@devs = dev1 dev2 dev3

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

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

这样，带有公共部分的

key\u type

类型的SSH密钥将映射到gitolite用户

user

，并强制使用指定的命令

---

萨克斯。我在第一篇文章中犯了一个“小”错误。我刚刚更改了它。我还使用“gitolite access”命令进行了访问检查。更新了我的答案，试图分析新的输入数据。

ssh-keygen -y

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