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:
parent
bfc3b6cd58
commit
604669ca02
21
README.mkd
21
README.mkd
|
@ -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]
|
||||
|
||||
----
|
||||
|
|
|
@ -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
|
||||
# -----------------------
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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;
|
||||
|
|
|
@ -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/);
|
||||
|
|
Loading…
Reference in a new issue