CODEWITHSUNDEEP
gitgitolite
Auric
Auric

Reputation: 170

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.

Upvotes: 1

Views: 150

Answers (1)

VonC
VonC

Reputation: 1324737

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.

Actually, the OP Auric comments below:

While the update hook was in place and I actually did use gitolite setup, I did this with another user.

Since I couldn't get fcgiwrap configured to run under another user, I had to make sure gitolite was installed under user git, but was executable using user www-data.
I used bindfs for this purpose.
But since I ran gitolite setup under user git, the update hook was symlinked to /home/git/.gitolite/... in stead of /opt/gitolite/.gitolite/...
So now I re-ran setup with /opt/gitolite as $HOME so that the symlink is correct.

Upvotes: 1

Related Questions