2016-10-15 6 views
1

Я убедил офис, что мы должны переехать в Git. Поскольку мы только начинаем, я настроил git-сервер, используя простой git и https перед ним, используя nginx. Мы не делаем использовать gitlab или что-то в этом роде - пока.Gitolite не соблюдает правила при доступе через httpd

Один из вопросов, который я получил, заключается в том, можно ли ограничить доступ к определенным ветвям (особенно мастер) для новых коллег. Это бы сэкономило нам массу неприятностей в прошлом :-)

Во время поиска решения я нашел 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 дает мне предупреждение о том, что это правило не имеет никакого смысла. Он игнорируется.

ответ

1

The gitolite dev notes упомянуть pre-git шаг как был журнал линия, которая появляется, когда проверка первого доступа успешно (т.е., перед тем git-upload-pack или git-receive-pack называется).

Однако в журнале не указан этап update: это шаг, который появляется, когда вторая проверка доступа завершается успешно (т. Е. Когда крюк update решает разрешить толчок).

Это означает, что update hook для этого репо может быть неправильным на месте (символическая ссылка в каждой папке переходов репозитория на сценарий обновления gitolite).
A gitolite setup должен заботиться об этих ссылках.

На самом деле, OP Auric комментарии below:

Хотя update крючок был на месте, и я на самом деле использовать gitolite setup, я сделал это с другим пользователем.

Поскольку я не мог fcgiwrap настроен для работы под другим пользователем, я должен был убедиться, что gitolite был установлен под пользователем git, но исполняемый файл с помощью пользователя www-data.
Я использовал bindfs для этой цели.
Но так как я побежал gitolite setup под пользователем git, то update крючок Так что теперь я установка вновь побежал с /opt/gitolite как $HOME так, что символическая правильно слинкован в /home/git/.gitolite/... в смену /opt/gitolite/.gitolite/...
.

+0

Я потратил на это часы, и вы направили меня на правильный ответ. Хотя крюк обновления был на месте, и я действительно использовал 'gitolite setup', я сделал это с другим пользователем. – Auric

+0

Поскольку я не мог заставить 'fcgiwrap' настроиться на запуск под другим пользователем, я должен был убедиться, что gitolite был установлен под пользователем' git', но был выполнен с использованием user 'www-data'. Для этой цели я использовал 'bindfs'. Но поскольку я запускал «gitolite setup» под пользователем 'git', крюк' update' был привязан к '/home/git/.gitolite/...' вместо' /opt/gitolite/.gitolite/... ' Итак, теперь я перезапустил настройку с'/opt/gitolite' как '$ HOME', чтобы символическая ссылка была правильной. Спасибо! – Auric

+0

@Auric Молодцы! Я добавил ваши комментарии в ответ для большей наглядности. – VonC