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.
Teemu's testing brought up a situtation I had not anticipated:
"repo foo/CREATER" looks like a non-regex, and its creation then (a)
goes by "W" permissions instead of "C" permissions, and (b) the
creater's name does not get recorded (no gl-creater file).
SIDE NOTE: one way is to reduce the paranoia, and just put the
creater name in anyway. Treat a repo created from gl-auth as a
wildcard-matched autovivified repo, because the *other* kind would
have actually got created by gl-compile anyway.
However, I can think of *one* very far-out situation where this
could backfire on an unwary admin, and I'm paranoid :-)
So we need to force it to look like a regex. Moving the line-anchoring
from `parse_acl` to gl-compile sounded fine, until I realised that the
"$" isn't easy. Backslashitis, bigtime, plus the single/double quote
tricks we're playing with the dumped hash adds its own complexities.
Best of both worlds, promote the "^" to gl-compile, keep the "$" where
it is...!
Git repository configurations can be set/unset by declaring "config"
lines in "repo" stanzas in gitolite.conf. For example:
repo gitolite
config hooks.mailinglist = gitolite-commits@example.tld
config hooks.emailprefix = "[gitolite] "
config foo.bar = ""
config foo.baz =
The firs two set (override) the values. Double quotes must be used to
preserve preceding spaces. Third one sets an empty value and the last
removes all keys.
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
we had usurped the email style syntax to separate multiple keys
belonging to the same person, like sitaram@desktop.pub and
sitaram@laptop.pub. If you have so many users that you need the full
email address to disambiguate some of them (or you want to do it for
just plain convenience), you couldn't.
This patch fixes that in a backward compatible way. See
doc/3-faq-tips-etc.mkd for details.
- new_repo now takes a "creater" parameter; if given, this user is
recorded (in a file called "gl-creater") as the creater of the repo.
Only applicable to wildcards
- repo_rights reads "gl-creater" and "gl-perms" to tell you who
created it, and whether you (the $user) are in the list of READERS
or WRITERS
**NOTE** that the mechanism to create/update gl-perms has not been
written yet... (as of this commit)
- parse_acl takes 4 more arguments, all optional. The repo name we're
interested in (set by all except the access reporting function), and
the names to be interpolated as $creater, $readers, writers
- report_basic now knows about the "C" permission and shows it
- auth now autovivifies a repo if the user has "C" and it's a wildcard
match, or (the old case) the user has "W" and it's not a wildcard.
In the former case, the creater is also set
IMPLEMENTATION NOTES:
- the Dumper code now uses a custom hash key sort to make sure
$creater etc land up at the *end*
- a wee bit of duplication exists in the update hook; it borrows a
little code from parse_acl. I dont (yet) want to include all of
gitolite.pm for that little piece...
There's a new "C" permission to let someone *create* a repo that matches
the pattern given in the "repo ..." line. If the word CREATER appears
in the repo pattern, then that is forced to the actual user performing
that operation.
Something like this (we'll discuss READERS and WRITERS later):
repo personal/CREATER/.+
C = @staff
R [foo] = READERS
RW [bar] = WRITERS
...various other permissions as usual...
Delegation checking also changes quite a bit... see comments in code
Implementation: there's also a sneaky little trick we're playing here
with the dumped hash
all of this is prep for the upcoming, all-new, chrome-plated,
"wildrepos" branch :)
- many variables go to gitolite.pm now, and are "our"d into the other
files as needed
- new functions parse_acl, report_basic to replace inlined code
consider:
repo = "some desc" # some comment
(and note that the regex for recognising a description expects that
dblquote to be the *last* character on the line)
part of comment on b78a720cee:
The only reason it's getting into master is because it looks cool!
I hate it when something that looks cool doesn't work right :(
creating a repo on gitolite-admin push is *needed* in order to get
descriptions and export-ok files to work right
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.
the "create a new repo" code moves from compile to auth.
Only someone who has W access can create it, but he can do so even on a
"R" operation (like clone or ls-remote).
This is a pre-requisite for rebel's wildcard repos, where
autovivification is the only way you can create arbitrary repos matching
a pattern.
The only reason it's getting into master is because it looks cool!
----
OK that's a lie; the real reason is to keep the two branches as similar
as possible, though they;ve diverged quite a bit since the "only
one-line difference" days where "rebel" just meant "deny/exclude"
rules!)
writing the export_ok files and the gitweb project list are now
unconditional. They're idempotent anyway, and I doubt anyone cared
about all the fancy logic to detect and report *just* the new ones on
each compile.
This paves the way for gitweb ownership to be added later; that code was
becoming too complex otherwise...
I was trying to determine how close gitolite can come to the ACL model
of a proprietary product called codebeamer, and one of the items was how
to make a "role" (like QA_Lead) have different "members" in different
projects.
I then realised delegation already does that! Which is great, but as I
thought about it more, I realised... well, we'll let the in-code
comments speak for themselves :-)
Anyway, all it needed was a 1-line fix, luckily... <phew> And it would
have only affected people who use delegation.
You can now add your own hooks into src/hooks/ and they get propagated
along with the update hook that is present there now. Please read the
new section in the admin document, and make sure you understand the
security implications of accidentally fiddling with the "update" script.
This also prompted a major rename spree of all the files to be
consistent, etc. Plus people said that the .sh and .pl suffixes should
be avoided (and I was feeling the same way). I've also been
inconsistent with that "gl-" prefix, so I cleaned that up, and the 00-
and 99- were also funny animals.
Time to get all this cleaned up before we get 1.0 :)
So these are the changes, in case you're looking at just the commit
message and not the diffstat:
src/pta-hook.sh -> src/ga-post-update-hook
src/conf-convert.pl -> src/gl-conf-convert
src/00-easy-install.sh -> src/gl-easy-install
src/99-emergency-addkey.sh -> src/gl-emergency-addkey
src/install.pl -> src/gl-install
src/update-hook.pl -> src/hooks/update
Packaging gitolite for debian requires the rc file to be in /etc/gitolite.
But non-root installs must still be supported, and they need it in $HOME.
This means the rc file is no longer in a fixed place, which needs code to find
the rc file first. See comments inside new file 'gitolite.pm' for details.
The rest of the changes are in the other programs, to replace the hard-coded
rc filename with a call to this new code.
