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)
[Please NOTE: this is all about *user* groups, not *repo* groups]
SUMMARY: gl-auth-commmand can now take an optional list of usergroup
names after the first argument (which is the username).
See doc/big-config.mkd in the next commit or so
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)
This commit series allows an admin to designate a set of commands that
users can run. For example, he can allow users to delete a repo that
they have created:
ssh git@server rmrepo foo/me/bar
or fork (to use github's terminology) a repo they have "R" access to,
into a new one they have "C" access to:
ssh git@server fork foo/someone-else/bar foo/me/bar
Please see documentation for details
----
(this commit)
- (rc) new variable $GL_ADC_PATH; without this none of this is enabled
- (pm) new helper routine "cli_repo_rights" to get rights/ownership
from outside
- (auth) call $GL_ADC_PATH/$cmd if it exists
This commit series refactors all the rights querying logic.
- old repo_rights sub renamed to wild_repo_rights
- new repo_rights sub to be a single entry point for most rights
queries
- callable from gl-auth-command and expand_wild
- callable from *outside* too, as long as $ENV{GL_USER} is set
- the format of the returned permissions contains C, R, and W as
applicable, with sigils reflecting the 3 possible ways in which you
can get R or W perms (2 ways for C):
@R means @all users have the same access
#R means you're a "super user" (think root's shell prompt) so
you can see all repos
R is the normal, explicit, access
All this is about a user trying to look if a repo exists or not, when he
does not have any access to that repo. Ideally, "repo does not exist"
should be indistinguishable from "you dont have perms to that repo".
(1) if $GL_WILDREPOS is not set, you either get a permissions error, or
a "$repo not found in compiled config" death. Fixed.
(2) if $GL_WILDREPOS is set, you either get either a permissions error,
or a "$repo has no matches" death. Fixed.
(3) The following combination leaks info about repo existence:
- actual repo doesn't exist
- spying user don't have C perms
- repo patt doesn't contain CREATER
- RW+ = CREATER is specified (as is normal)
In such case, the "convenience copy" of the ACL that parse_acl
makes, coupled with substituting CREATER for the invoking user means
$repos{$actual_repo} has RW+ for the spying user. This means the
access denied doesn't happen, and control passes to git, which
promptly expresses it unhappiness and angst over being given a repo
that 'does not appear to be a git repository'
This doesn't happen if all those conditions are not met:
- if repo exists, CREATER is set to the real creater, so RW+ =
CREATER does not gain spying user anything
- if spying user has C perms it just gets created, because he has
rights. This is also info leak but we can't prevent it; tighten
the config (maybe by including CREATER in repo pattern) if this
is not wanted
- if repo patt contains CREATER it will never match someone else's
repo anyway!
- 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...
Currently the pattern of expand command is line anchored. This is
different than in e.g. grep, and causes extra work to add '.*' prefix
and/or suffix in many use cases.
The new semantics now mean you might get more matches than you would
have gotten earlier. However, the expand command is still totally
undocumented, so I think it is acceptable to change the functionality.
;)
This patch removes the anchoring. So for earlier behavior the specified
pattern needs be in form of '^<pattern>$'. The default pattern is also
changed from '.*' to '^', so there might be even a small speed
improvement. =)
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
[TODO: allow a callback for a password checking function, such as
"passwd_policy_check". Question is where the function would go.
~/.gitolite.rc is the only possible place among the current set of files
but I'd rather leave that as a list of simple name=value lines for all
sorts of reasons. So maybe something like ~/.gitolite.pm (analogous to
the "gitolite.pm" in the sources I supply), which would get "require'd"
if found, and would contain all user-defined functions like this one...
needs some thinking about]
(about this commit)
The install doc now describes both the ways of installing gitolite.
It also has a handy appendix for package maintainers describing what
they need to do.
(about the "dps" -- distro packaging support -- commit series)
This commit is the last in the chain meant to make gitolite more
friendly for package maintainers.
Frankly, I never really thought gitolite would get big enough or
important enough for someone to package it, and I always did just
the bare minimum I needed to get it working, first for myself, then
anyone who hopped onto #git and asked. As a result, it had some
quirks in terms of what is expected where and so on...
Luckily, it didn't take a lot of changes to fix it, and this series
of commits should help make it very easy to package gitolite for
system-wide use.
The old install method will now use conf/VERSION instead of src/VERSION everywhere.
The new one, if you use the builtin make file to "make branch.tar" will also create just such a file
if you have read access to the admin repo, you can say
ssh git@server info user1 [...]
Original idea and code by Karteek E. The motivation is to quickly and
easily check what perms a user has. Technically nothing that you can't
glean from the config file itself but it serves as a double check or a
mild debugging aid perhaps.
However note that the branch level rules are much more complex and they
do not, as yet, have any such "helpful" aids. Life is like that
sometimes.
Although I have washed my hands off the security aspect if you use
external commands, that doesn't mean I won't make them as tight as I can
;-) Right now, this is just a place holder -- if people use it and
complain that the pattern is too restrictive, I'll change it.
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).
Allow users to set and display description (for gitweb) for their
own wildcard repositories using ssh commands:
setdesc <repo>
getdesc <repo>
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
brought on by realising that you lost $shell_allowed when refactoring
(previous commit) but perl hadn't caught it because -- damn -- you
didn't have "use strict" in gitolite.pm
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
great idea by Robin Smidsrød: since users are already capable of
authenticating themselves to gitolite via ssh keys, use that to let them
set or change their own HTTP passwords (ie, run the "htpasswd" command
with the correct parameters on behalf of the "git" user on the server)
code, rc para, and documentation. In fact everything except... ahem...
testing ;-)
and while we're about it, we also reorganised the way these helper
commands (including the venerable "info" are called)
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.
Mpenz asked what would happen if the config looked like
repo foo/abc
R sitaram
repo foo/.*
RW sitaram
If you asked for an expand of '.*', it would pick up permissions from
the second set (i.e., "RW") and print them against "foo/abc".
This is misleading, since those are not the permissions that will
actually be *used*. Gitolite always uses the more specific form if it
is given, which means your actual permissions are just "R".
This patch is to prevent that misleading reporting in this corner case.
- see *all* wildcard repos you have access to (this uses line-anchored
regexes as described in doc/4). Examples:
ssh git@server expand '.*'
ssh git@server expand 'assignment.*'
- show perms like the info command does
Please see comments against 02cee1d for more details and caveats.
gitolite specific ssh commands ("getperms", "setperms", "info" etc.)
should exit with non-error code in case of success.
Also "get/setperms" should print to STDOUT instead of STDERR.
This change is specially needed for the gitolite-tools
(http://github.com/tmatilai/gitolite-tools) to work.
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
we've removed the facility of auto-viving "W" access repos when they are
not wildcards. A wildcard pattern like foo/CREATER was
indistinguishable from a non-wildcard repo, and resolving it was
becoming kludgier and kludgier. (See the revert in the commit before
this one for details).
As a side effect of not being able to distinguish wildcard repos from
real repos easily, the expand command now works for a normal repo too
(because we have to make it work for "foo/CREATER")
