They don't work if someone calls the script for example
su - gitolite -c gl-setup <key>
from a directory where "gitolite" user does not have permissions (e.g.
0700), then 'cd $od' fails and we stay in gitolite's $HOME.
[commit message changed by committer; author was more polite ;-)]
(we quietly do not document the 'able' adc, which is now the most
"official" adc in the sense that it has a new test, t64-write-able!)
other notes: fix bug in 'able' (not setting $loc)
- openssh 5.6 doesn't like "ssh user@host" with no command following
it, because they changed the rules for pty allocation failure.
I'm calling this a BSD compat change because BSD hit it first, but
really, the "ssh -T" will eventually be needed by Linuxes also, as
they start upgrading to openssh 5.6
- FreeBSD (and I presume the other BSDs also) *require* a "-t"
argument to mktemp (thanks to matias for finding this).
Note that on FreeBSD, -t is a prefix (the X's are taken literally,
and the real random stuff gets appended to the prefix), while on
Linux, it is a template (the X's are converted to random
characters). Thus, on BSD you will get names like
/tmp/tmp.XXXXXXXXXX.1BAEGkHm, whereas on Linux you'll get
/tmp/tmp.Aq7vbdNpGp or something.
Use case: group information is generated from an external system and
because of synchronization or authorization restrictions some groups
can be empty.
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO
NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade
means should be fine, though.
Originally, we only allowed "R" and "RW" as categories of users supplied
to the `setperms` command. These map respectively to "READERS" and
"WRITERS" in the access rules.
Now:
- we prefer READERS instead of R and WRITERS instead of RW
- we allow the admin to define other categories as she wishes
(example: MANAGERS, TESTERS, etc). These do not have abbreviations,
however, so they must be supplied in full.
PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for
more info. This is a VERY powerful feature and if you're not careful
you could mess up the ACLs nicely.
Backward compat note: you can continue to use the "R" and "RW"
categories when running the "setperms" command, and gitolite will
internally convert them to READERS and WRITERS categories.
----
implementation notes:
- new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of
the allowed categories in a gl-perms file; defaults to "R RW" if not
specified
- wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if
"R $user", $r = '@all' if "R @all", and similarly with $w and "RW".
Instead it returns $c and a new hash that effectively gives the same
info, but expanded to include any other valid categories (listed in
GL_WILDREPOS_PERM_CATS)
- consequently, the arguments that parse_acl takes also change the
same way
- (side note: R and RW are quietly converted to READERS and WRITERS;
however, new categories that you define yourself do not have
abbreviations)
- setperms validates perms to make sure only allowed categories are
used; however even if someone changed them behind the scenes,
wild_repo_rights will also check. This is necessary in case the
admin tightened up GL_WILDREPOS_PERM_CATS after someone had already
setperms-d his repos.
- as a bonus, we eliminate all the post-Dumper shenanigans, at least
for READERS and WRITERS. Those two now look, to the compile script,
just like any other usernames.
This was a very old quirk/oddity. Doing
R = @all alice
would fail, but you could still do
R = @all
R = alice
Now we fixed it so it's consistent.
----
This also fixed a curious bug that no one ever caught:
@all = u1 u2 # yes -- there was no check on redefining @all
repo foo
R = @all u3 # now would not fail because of defining @all
would have given only those 3 users R access to foo, not really @all
users! This was because the previous failure message was an artifact of
not finding an expansion for @all, not a genuine "why are you saying
@all and then specifying some user explicitly" warning!
The old method of passing in usergroup info had some problems, which are
now fixed. It is also much easier to use now -- no more "wrapper"
script, plus it should work identially whether you use sshd or httpd.
See doc/big-config.mkd for details on the new method.
----
Notes on problems with the old method:
The old method for passing in usergroup info consisted of tacking them
on as extra arguments to gl-auth-command, after the username.
However, there are some problems with this method.
Some actions in gitolite look for permissions for users other than the
invoking user. Determining permissions for gitweb and daemon is one.
An admin asking for "info" on some other user, is another.
However, the list of groups sent in via the command line
pertains only to the invoking user, so these actions don't work
correctly. They may even pick up the wrong permissions.
What it all boils down to is that we need group information for any user
dynamically, instead of being passed a (static) list just for the
invoking user.
- hardcode 0700 mode for GL_ADMINDIR tree (thanks to ma at
ibitsense.com) for catching this
- honor REPO_UMASK for GL_REPO_BASE_ABS creation
- plus a minor doc update
for people who don't get the continual reference to towels when talking
about the "gl-dont-panic" program, all I can say is that your education
is incomplete ;-)
TODO: if the verb doesn't actually contain "git-receive-pack", I am
assuming it is some sort of read. The list in services[] in
http-backend.c does not seem to look like any other verb is a "write";
need to check this with someone.
For normal git commands:
- PATH_INFO gives you the repo name
- REQUEST_URI gives you the verb
- we construct a fake SSH_ORIGINAL_COMMAND so the rest of the
processing does not have to change
For our special commands:
- PATH_INFO is actually the verb
- QUERY_STRING has the parameters
- we again fake out the SSH_ORIGINAL_COMMAND
- we print the extra HTTP headers in anticipation of the actual output
Either way, we also fake out the SSH_CONNECTION so that the IP address
can get logged ok
And of course REMOTE_USER is now the incoming userid
Finally, at the end, we exec GIT_HTTP_BACKEND instead of the normal one
adapted from code by kpfleming@digium.com. I basically cherry-picked
the top commit on "pu-work" (30068d1) on his fork at github, and made
some minor fixups to it
By default, @all does not include gitweb and daemon, but if that's what
you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL
variable in conf/example.gitolite.rc
This should hopefully be the final step in making wildrepos as close to
normal repos as possible. You can now do pretty much anything with them
that you can do with normal repos [1]
Implementation notes:
- compile puts out %groups into the compiled config file regardless of
GL_BIG_CONFIG because this feature needs it
- wild_repo_rights caches %groups because the part of the %groups hash
we care about will not change between calls in the same run
----
[1] **except** use the full-blown config file syntax within the gl-perms
file :-) I don't plan to do that; it's too complicated! [2]
[2] yeah yeah I know -- famous last words!
modifications:
- call setup_gitweb_access and setup_daemon_access from with
get_set_perms so when the user sets a perm explicitly it works
- in setup_gitweb_access, do not delete description file or
gitweb.owner if the repo is wild
- make the "fork" adc set gitweb.owner *and* call setperms using
GL_WILDREPOS_DEFPERMS
- add tests
bug fixes:
- gl-auth did not even *look* at GL_WILDREPOS_DEFPERMS when
auto-"C"reating a wild repo; fixed
- setup_gitweb_access did not delete the description file as
consistently as it deleted the owner
what will NOT work:
- removing gitweb permissions does not clear the name from
"projects.list". That's complicated, so just wait till the next
"compile" to make this happen
(thanks to Jefferai for driving this...)
----
mildly puzzling:
for some strange reason, after a "git ls-remote ...try3" in t58,
instead of not creating a "description" file, we started seeing a
73-byte file containing this message:
Unnamed repository; edit this file 'description' to name the repository.
I'm an idiot. I say I won't do it, then I go and do it anyway.
Fortunately, in this case, the code and execution remain exactly the
same for people who do not set $GL_PERFLOGT in the rc file, so it's
tolerable.
<evil grin> People who want even more than this can contact Greg Lonnon
(see the mailing list archives at
http://groups.google.com/group/gitolite for an obfuscated but easy to
guess email address) ;-)
plus it can also be matched by a normal repo line. In other words, with
repo foo/bar
RW = u1
repo foo/..*
RW = u2
user u2 has access to foo/bar (the non-wild does not cause the wild to
be completely ignored any longer)
implementation notes:
get_memberships:
- no more highlander ("there can only be one") for patterns in
@repo_plus
- return $wild as a space-separated list of matched patterns
collect_repo_patts:
- as of the last change to this section of code it appears we
weren't using the values anyway, but I had forgotten :-)
repo_rights: (big change: $wild no longer implies $creator present,
or vice versa)
- new type of "creator" (like "was_sitaram") is now possible
Implementation notes:
- %repo_config is now "our", not "my"
- collect_repo_patts now uses repo_rights to get the name of the wild
card repo (if any) that pertains to the physical $repo, instead of
all that new code (duh!)
- new "can_read(repo, user)" sub (to help daemon and gitweb use)
- the "convenience copy on steroids" thing now copies %repo_config
also, not just %repos. This makes setup_repo_configs simpler
- $creator gets substituted into %groups also; we need that now that
we (%repos and %groups) are working closer together :)
(thanks to Kevin Fleming for the need/use case)
TODO: tests
TODO: proper documentation; meanwhile, just read this:
- you can give gitweb and daemon read rights to wild card repos also,
and it'll all just work -- when a new repo is 'C'reated, it'll pick
up those rights etc
- you can assign descriptions (and owners) to individual repos as
before, except now you can assign them to repos that actually were
created from wild card patterns. So for example, you can define
rules for
repo foo/..*
and then assign descriptions like
foo/repo1 = "repo one"
foo/repo2 = "repo two"
foo/dil "scott" = "scott's dilbert repo"
However, this only works for repos that already exist, and only when
you push the admin repo.
Thumb rule: have the user create his wild repo, *then* add and push
the admin config file with the description. Not the other way
around.
implementation notes:
- wildcard support for git config revamped, refactored...
it's not just git config that needs wildcard support. daemon and
gitweb access also will be needing it soon, so we start by factoring
out the part that finds the "pattern" given a "real" repo name.
- GL_NO_DAEMON_NO_GITWEB now gates more than just those two things;
see doc/big-config.mkd for details
- we trawl through $GL_REPO_BASE_ABS *once* only, collecting repo
names and tying them to either the same name or to a wild pattern
that the repo name was created from
- nice little subs to setup gitweb, daemon, and git config
- god bless $GL_REPOPATT and the day I decided to set that env var
whenever a user hits a wild repo in any way :-)
- the code in gl-compile-conf is very simple now. Much nicer than
before
