There were 2 problems with rule sequencing.
Eli had a use case where everyone is equal, but some are more equal than
the others ;-) He wanted a way to say "everyone can create repos under
their own names, but only some people should be able to rewind their
branches".
Something like this would be ideal (follow the rules in sequence for
u1/u2/u3/u4, and you will see that the "deny" rule kicks in to prevent
u1/u2 from being able to rewind, although they can certainly delete
their branches):
@private-owners = u1 u2
@experienced-private-owners = u3 u4
repo CREATOR/.*
C = @private-owners @experienced-private-owners
RWD = CREATOR
RW = WRITERS
R = READERS
- = @private-owners
RW+D = CREATOR
In normal gitolite this doesn't work because the CREATOR rules (which
get translated to "u1" at runtime) end up over-writing the "deny" rule
when u1 or u2 are the creators. This over-writing happens directly at
the "do compiled.pm" step.
With big-config, this does not happen (because @private-owners does not
get expanded to u1 and u2), but the problem remains: the order of
picking up elements of repo_plus and user_plus is such that, again, the
RW+D wins (it appears before the "-" rule).
We fix all that by
- making CREATOR complete to more than just the creator's name (for
"u1", it now becomes "u1 - wild", which is actually illegal to use
for real so there's no possibility of a name clash!)
- maintaining a rule sequence number that is used to sort the rules
eventually applied (this also resulted in the refex+perm hash
becoming a list)
Since it is possible to do all sorts of shenanigans with wildcards and
repo groups, we
- allow only a fragment called "foo" to set permissions for a group
called "@foo", in addition to a repo called "foo"
- forbid defining any groups within a fragment conf. All "@foo = bar
baz" must be done in the main config file now.
If this proves too limiting for anyone I'll worry about it then.
If you have many thousands of repos and users, neatly organised into
groups, etc., the normal gitolite fails. (It actually runs out of
memory very fast while doing the "compile" when you push the config, due
to the number of combinations of repo/user being stored in the hash!)
This commit series will stop doing that if you set $GL_BIG_CONFIG = 1 in
the rc file.
Some notes:
- deny rules will still work but somewhat differently -- now they must
be placed all together in one place to work like before. Ask me for
details if you need to know before I get done with the docs
- I've tested most of the important features, but not every single
nuance
- the update hook may be a tad less efficient now; we can try and
tweak it later if needed but it shouldn't really hurt anything
significantly even now
- docs have not been written yet
Ouch! How mortifying :) I'd always thought this was one of the Brit/US
differences, but to find out that it really *isn't* a word... hmph!
Anyway, in the interest of not breaking existing wild repos, the
ownership file is still called "gl-creater". Everything else has been
changed.
(...thanks to Sverre)
Having to specify "D" separately from RW or RW+ was cumbersome, and
although I don't actually use this feature, I can see the point.
One way to think of this is:
- RW and RW+ were the only existing branch level rights
- it doesnt make sense to have D rights without W (hence RW) rights
- so we simply suffix a D to these if required.
Thus you can have RW, RW+, RWD, RW+D.
I hope the (hopefully few) of you who have started to use this feature
will convert your configs when you next upgrade to "pu".
I now regret pushing the previous syntax to master too quickly -- lots
of people use master only, and on the next promotion of pu the syntax
will change. To reduce this exposure, this change will be promoted to
master very soon.
Previous implementations of "give shell access to some gitolite users"
feature were crap. There was no easy/elegant way to ensure that someone
who had repo admin access would not manage to get himself shell access.
Giving someone shell access requires that you should have shell access
in the first place, so the simplest way is to enable it from the server
side only.
So now that we decided to do that, we may as well prepare for other,
future, commands by starting a server-side utility program with
sub-commands (the only current one being "shell-add")
normally, RW+ means permission to rewind or delete.
Now, if you use "D" permission anywhere in a repo config, that means
"delete" and RW+ then means only "rewind", no delete.
- no need to put it at the end of the config file now, yeaaay!
- @all for @all is meaningless and not supported. People asking will
be told to get a life or use git-daemon.
- NAME/ limits for @all repos is ignored for efficiency reasons.
Data dumper was failing (returning an empty string!) on an input config
file of about 350 lines or so (output 2400 lines or so).
Removing the sort sub fixed the problem.
To recap why that sub was put in (see deleted lines in this commit for
details), what we really want is that $creater must appear *last* in the
resulting dump.
So we trick it. "man ascii" tells you that ~ is the highest valued
ASCII character (yes, I know, not utf-8 safe etc... I'll deal with that
if and when needed or punt!). So we just put that in front of $creater
and remove it later...
You *don't* want to do this for $readers and $writers -- then they will
once again sort *after* $creater, which would be a bad thing. Also,
it's probably better this way, because now the order of the hash keys
will be: $readers, $writers, any actual users listed, and then $creater.
This means the effective access rights will be:
1. if you are the creater you get CREATER's rights
2. else if your userid is listed *explicitly* in the config, you get
those rights
3. else if you've been setperm'd as a writer, you get WRITERS rights
4. else if you've been setperm'd as a reader, you get READERS rights
This is different from what used to happen till now; READERS and WRITERS
used to trump explicitly given rights. I'd been meaning to fix that
somehow, but never got around to it, until this DDD (damn Data Dumper!)
forced my hand :)
The new style personal branches work by interpreting the special
sequence /USER/ (including the slashes) in a refname. Docs should be in
the next commit...
when repos are copied over from elsewhere, one had to run easy install
once again to make the new (OS-copied) repo contain the proper update
hook.
We eliminate this step now, using a new, empty, "hook" as a sentinel and
having "compile" check/fix all repos' hooks.
Since you have to add the repos to conf anyway, this makes it as
seamless as possible. The correct sequence now is
- (server) copy the repo at the OS level
- (admin clone) add it to conf/gitolite.conf, commit, push
let expand_list be just that "expand a list", and leave checking to be
done outside.
otherwise, commit 690604d79 has the side effect of restricting refs to
$REPOPATT_PATT, and so for instance barfing on the perfectly valid
RW+ refs/(?!heads/master) = alice bob
(thanks to Teemu for catching this)
this came up in some other discussion with bremner. As usual I said no
I won't do it because I don't see any real need.
...then I realised it's just one line :)
Gitolite allows you to set git repo options using the "config" keyword;
see conf/example.conf for details and syntax.
However, if you are in an installation where the repo admin does not
(and should not) have shell access to the server, then allowing him to
set arbitrary repo config options *may* be a security risk -- some
config settings may allow executing arbitrary commands.
This patch fixes it, introducing a new RC variable to control the
behaviour. See conf/example.gitolite.rc for details
The wildrepos branch has been merged into master, and deleted. It will no
longer exist as a separate branch. Instead, a new variable
called $GL_WILDREPOS has been added which acts as a switch; when
off (which is the default), many wildrepos features are disabled.
(the "C" permissions, and the getperms (etc.) commands mainly).
Important: if you are using wildrepos, please set "$GL_WILDREPOS = 1;" in
the RC file when you upgrade to this version (or just before you do the
upgrade).
lots of conflicts, esp in gl-auth-command, due to refactoring the
"special commands" stuff on master
Conflicts:
doc/3-faq-tips-etc.mkd
src/gitolite.pm
src/gl-auth-command
src/gl-compile-conf
Gitolite uses projects.list to set the owners for gitweb's use.
Unfortunately, this does not work for gitweb setups that set
$projectroot to a directory, thus generating the list of
repositories on the fly.
This patch changes that: gitolite now writes the gitweb.owner
configuration variable for each repository (and properly cleans up after
itself if the owner is removed).
The patch causes gitolite not to write the owner to projects.list
anymore, as this would be redundant.
The owner also needs no longer be escaped, so this patch removes the
poor man's 's/ /+/g' escaping previously in place.
Note that I am not a Perl coder. Thus there are probably better ways to
implement this, but at least it works.
Cc: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: martin f. krafft <madduck@madduck.net>
This is actually a pretty big deal, and I am seriously starting wonder
if calling this "gito*lite*" is justified anymore.
Anyway, in for a penny, in for a pound...
This patch implements a generic way to allow access control for external
commands, as long as they are invoked via ssh and present a server-side
command that contains enough information to make an access control
decision.
The first (and only, so far) such command implemented is rsync.
Please read the changes in this commit (at least the ones in conf/ and
doc/) carefully.
The way pubkey files are handled by gitolite, this could be used by a
repo admin to get shell access. It's always been there as an
undocumented emergency mechanism for an admin who lost his shell keys or
overwrote them due to not understanding ssh well enough (and it has been
so used at least once).
But not any more...
Like the @SHELL case, this reflects a shift away from treating people
with repo admin rights as eqvt to people who have shell on the server,
and systematically making the former lesser privileged than the latter.
While in most cases (including my $DAYJOB) these two may be the same
person, I am told that's not a valid assumption for others, and there've
been requests to close this potential loophole.
Stop conflating the privilege to push changes to the admin repo with the
privilege to get a shell on the server.
Please read doc/6 carefully before upgrading to this version. Also
please ensure that the gitolite key is *not* your only means to get a
command line on the server
Support config file including using:
include "filename"
If filename is not an absolute path, it is looked from the
$GL_ADMINDIR/conf/ directory.
For security reasons include is not allowed for fragments.
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
(this commit will probably get reverted after a suitable period has
elapsed and no one is likely to still be using the old syntax).
Forgetting to change it to NAME/ after is a security issue -- you end up
permitting stuff you don't want to!
This commit allows the old syntax but prints a warning
Gitolite allows you to restrict changes by file/dir name. The syntax
for this used "PATH/" as a prefix to denote such file/dir patterns.
This has now been changed to "NAME/" because PATH is potentially
confusing.
While this is technically a backward-incompatible change, the feature
itself was hitherto undocumented, and only a few people were using it,
so I guess it's not that bad...
Also added documentation now.
"repo @all" can be used to set permissions or configurations for all
already defined repos. (A repository is defined if it has permission
rules associated, empty "repo" stanza or "@group=..." line is not enough.)
For example to allow a backup user to clone all repos:
# All other configuration
[...]
repo @all
R = backup
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
This reverts commit 33fc0a7e9f.
Was causing too much trouble with access reporting (basic and expanded)
because of the extra ^ at the start...
The paranoia referred to in that commit was this sequence:
- admin creates a named (non wildcard) repo using config file push
- somehow that gets deleted (OS error, corruption, ...)
- admin just asks anyone with a current repo to push it to auto-revive
it (because we allow people with "W" access to non-wildcard repos to
auto-viv repos)
- if you're treating this the same as a wildcard creation, you end up
making this guy the "creater" of that repo, which means he can add
users etc...
We resolve that paranois by disallowing autoviv of "W" access repos at
all... Only "C" access repos can be autovived by a user (this will be
in the next commit)
