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)
The admin repo's post-update hook needs to know where $GL_ADMINDIR is,
and we had a weird way of doing that which depended on gl-install
actually munging the hook code.
We also always assumed the binaries are in GL_ADMINDIR/src.
We now use an env var to pass both these values. This removes the weird
dependency on gl-install that the post-update hook had, as well as make
running other programs easier due to the new $GL_BINDIR env var.
