Auric Auric - 1 month ago 6
Git Question

Gitolite doesn't respect rules when accessed through httpd

I convinced the office that we should move to Git. Because we're just starting, I set up a git server using plain git and https in front of it using nginx. We don't use gitlab or something like that - for now.

One of the questions I got is whether it would be possible to restrict access to specific branches (especially master) for new colleagues. It would have saved us a lot of trouble in the past :-)

During my search for a solution, I found gitolite very promising so I tried it out and set it up. I got git up and running through gitolite so I started to dig into the rules.

However, I cannot get them right. It seems like gitolite ignores the second check

My

gitlolite-admin/conf/gitolite.conf
looks like this (I had a more complex one but while debugging I stripped it down to the bare minimum)

@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


In the docs it is specified that you can trace the access control decision.

output of
gitolite access -s playground auric
is this

pull access

$ 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/.*


push access

$ 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$


rewind push access

$ 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$


push access on another branch

$ 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/.*


exactly what I expected it to be.
and indeed, this is what I see in
~/.gitolite/logs
after executing these commands (I stripped the date here):

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


However, when I actually start using git and perform a push (and even a rewind push) through httpd, all commands are allowed and I see this in the logs

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


as if only check 1 is done but check 2 never comes.

What do I miss here?

edit I'm using gitolite3. I know some answers are around about adding the rule
R master = @starters
but then gitolite gives me the warning that that rule doesn't make any sense. It is ignored.

Answer

The gitolite dev notes mention the pre-git step as being the log line which appears when the first access check succeeds (i.e., before git-upload-pack or git-receive-pack is called).

However, the update step is not listed in the log: it is the step which appears when the second access check succeeds (i.e., when the update hook decides to allow the push).

That means the update hook for that repo might not be correctly in place (symlink in each repo hooks folder to the gitolite update script).
A gitolite setup is supposed to take care of those links.

Comments