rebel edition -- cos when you need it, you need it bad :-)

Summary: much as I did not want to use "excludes", I guess if we don't put the
code in "master" it's OK to at least *write* (and test) the code!

See the example config file for how to use it.

See "design choices" section in the "faq, tips, etc" document for how it
works.
This commit is contained in:
Sitaram Chamarty 2009-09-18 18:03:53 +05:30 committed by Sitaram Chamarty
parent bfc3b6cd58
commit 604669ca02
5 changed files with 93 additions and 1 deletions

View file

@ -3,6 +3,27 @@
> [Update 2009-10-28: apart from all the nifty new features, there's now an
> "easy install" script in the src directory. This script can be used to
> install as well as upgrade a gitolite install. Please see the INSTALL
> ----
> ***REBEL FORK WARNING***
> The paranoid half of Sitaram's brain would like to warn you that the other
> half rebelled and created this fork.
> 1. please read the "design choices" section in the [faqs, tips, etc]
> [fted] document for background
> 2. please read the comments in the example.conf file carefully before
> creating your own config file
> 3. please test your configuration carefully
> 4. if you still have problems and contact me, please mention right up
> front that you're using the ***rebel edition***; makes it easier to
> troubleshoot
[fted]: http://github.com/sitaramc/gitolite/blob/rebel/doc/3-faq-tips-etc.mkd
----
> document in the doc directory for details]
----

View file

@ -123,6 +123,26 @@ repo git
RW tmp/ = @all
RW refs/tags/v[0-9] = junio
# REBEL BRANCH -- DENY/EXCLUDE RULES
# please see the "faq, tips, etc" document for details on the "rebel" edition.
# in the example above, you cannot easily say "anyone can write any tag,
# except version tags can only be written by junio". The following might look
# like it works but it doesn't:
# RW refs/tags/v[0-9] = junio
# RW refs/tags/ = junio linus pasky @others
# in the "rebel" branch, however, you can do this:
RW refs/tags/v[0-9] = junio
- refs/tags/v[0-9] = linus pasky @others
RW refs/tags/ = junio linus pasky @others
# Briefly, the rule is: the first matching refex that has the operation you're
# looking for (`W` or `+`), or a minus (`-`), results in success, or failure,
# respectively. A fallthrough also results in failure
# GITWEB AND DAEMON STUFF
# -----------------------

View file

@ -22,6 +22,7 @@ In this document:
* design choices
* keeping the parser and the access control separate
* why we don't do "excludes"
* how the rebel edition does it anyway :)
### common errors and mistakes
@ -527,3 +528,52 @@ The lack of overlap between refexes ensures ***no confusion*** in specifying,
understanding, and ***auditing***, what is allowed and what is not.
And in security, "no confusion" is a good thing :-)
#### how the rebel edition does it anyway :)
Well, reuss on #git asked, I pointed him to the discussion above and said
"no", and he was nice enough to agree. But then I started thinking that maybe
not everyone needs such "safe" environments. And so, as the README says:
> The paranoid half of Sitaram's brain would like to warn you that the other
> half rebelled and created this fork.
Let's recap the **existing semantics**:
> the first matching refex that has the permission you're looking for (`W`
> or `+`), results in success. A fallthrough results in failure
First I changed the format of the compiled config file (an internal file that
the user doesn't have to worry about, as long as he remembers to run the
compile script on every upgrade). The format change kept the existing syntax
and semantics of the config file, but it laid the ground work for allowing
"excludes" using **just one extra line of code** (and a very slight change to
another)!
This extremely small delta between the rebel edition and the main one will
make it trivial to maintain it as a separate branch, regardless of what other
changes happen in the mainline, because I honestly don't see rebel merging
into the mainline.
Yet ;-)
Here are the **rebel semantics**, with changes from the "main" one in bold:
> the first matching refex that has the permission you're looking for (`W`
> or `+`) **or a minus (`-`)**, results in success **or failure,
> respectively**. A fallthrough **also** results in failure
So the example we started with becomes, in the rebel edition:
RW refs/tags/v[0-9].* = bruce
- refs/tags/v[0-9].* = @staff
RW refs/tags = @staff
And here's how it works:
* for non-version tags, only the 3rd rule matches, so anyone on staff can
push them
* for version tags by bruce, the first rule matches so he can push them
* for version tags by staffers *other than bruce*, the second rule matches
before the third one, and it has a `-` as the permission, so the push
fails

View file

@ -186,7 +186,7 @@ sub parse_conf_file
@repos = expand_list ( @repos );
}
# actual permission line
elsif (/^(R|RW|RW\+) (.* )?= (.+)/)
elsif (/^(-|R|RW|RW\+) (.* )?= (.+)/)
{
my $perms = $1;
my @refs; @refs = split(' ', $2) if $2;

View file

@ -85,6 +85,7 @@ sub check_ref {
$refex = (keys %$ar)[0];
# refex? sure -- a regex to match a ref against :)
next unless $ref =~ /$refex/;
die "$perm $ref $ENV{GL_USER} DENIED by $refex\n" if $ar->{$refex} eq '-';
# as far as *this* ref is concerned we're ok
return if ($ar->{$refex} =~ /\Q$perm/);