拒絕寫入訪問特定的分支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並被強制使用指定的命令。