now you can disallow creation of new refs if you like

see doc/3 for details (look for "separating delete and rewind rights"

----

and for gerrit, this is one more thing it can do that we can too ;-)

[the original text was somewhat misleading.  We mean "prevent someone
from creating a branch that they have permissions to push".  That is
what is now possible, where it was not possible before.]
This commit is contained in:
Sitaram Chamarty 2010-06-01 21:13:38 +05:30
parent 18267706db
commit 6d32e4e920
4 changed files with 38 additions and 5 deletions

View file

@ -92,10 +92,6 @@ review stuff :)
* gitolite doesnt do anything special to signed or annotated tags
* gitolite always allows creating a branch. The only way to prevent that is
to list out allowed branches explicitly (make sure you end the refex with
a `$`!).
* Force push is the same as delete: historically (and by default, even now)
gitolite does the same . However, I've only recently (and somewhat
reluctantly) changed gitolite to allow treating these two separately.

View file

@ -18,6 +18,7 @@ In this document:
* <a href="#better_logging">better logging</a>
* <a href="#exclude_or_deny_rules">"exclude" (or "deny") rules</a>
* <a href="#separating_delete_and_rewind_rights">separating delete and rewind rights</a>
* <a href="#separating_create_and_push_rights">separating create and push rights</a>
* <a href="#file_dir_NAME_based_restrictions">file/dir NAME based restrictions</a>
* <a href="#delegating_parts_of_the_config_file">delegating parts of the config file</a>
* <a href="#convenience_features">convenience features</a>
@ -381,6 +382,40 @@ message when you push, a non-existant user.
[sdrr]: http://groups.google.com/group/gitolite/browse_thread/thread/9f2b4358ce406d4c#
<a name="separating_create_and_push_rights"></a>
##### separating create and push rights
[note: the documentation took longer to write than the code ;-)]
Now you can disallow creation of new refs if you like.
Normally, when you try to update a ref (push a branch or a tag), it's checked
against all the refexes, and if none of them match for the operation you're
trying (W or +), or it matches a "-", the operation is denied.
That is, most refs are default "deny".
`CREATE_REF` is a "fake" refex that controls the ability to *create* a branch,
even if you are allowed to *push* changes to it.
The right to create a ref (i.e., push a brand new one), however, defaults to
"accept" unless a deny rule is found. This is mainly for backward compat
reasons, but also because this feature is rarely needed, so there's no point
burdening everyone with having to create the opposite rule.
So if you want to prevent someone from *creating* any branches that they
otherwise *can* push, make sure that the first rule that applies to them is a
`- CREATE_REF` rule, like line #3 below:
repo foo
RW+ = @leads
- CREATE_REF = @devs
RW+ = @devs
One side effect is that you now can no longer have an *actual* branch called
`CREATE_REF`. Oh well, into each life some rain must fall!
<a name="file_dir_NAME_based_restrictions"></a>
##### file/dir NAME based restrictions

View file

@ -82,6 +82,8 @@ push @allowed_refs, @ { $repos{$ENV{GL_REPO}}{'@all'} || [] };
# been specified
my @refs = ($ref); # the first ref to check is the real one
# if a new ref is being created, add a special ref to record that
push @refs, 'refs/heads/CREATE_REF' if $oldsha eq '0' x 40;
# because making it work screws up efficiency like no tomorrow...
if (exists $repos{$ENV{GL_REPO}}{NAME_LIMITS}) {
# this is special to git -- the hash of an empty tree

View file

@ -87,7 +87,7 @@ sub check_ref {
# as far as *this* ref is concerned we're ok
return $refex if ($ar->[2] =~ /\Q$perm/);
}
die "$perm $ref $repo $ENV{GL_USER} DENIED by fallthru\n";
die "$perm $ref $repo $ENV{GL_USER} DENIED by fallthru\n" unless $ref eq 'refs/heads/CREATE_REF';
}
# ln -sf :-)