Commit graph

267 commits

Author SHA1 Message Date
Sitaram Chamarty 5ad2056a9c typo fix in doc/4; thanks Teemu! 2010-01-08 06:20:19 +05:30
Sitaram Chamarty ab3c861241 Revert "easy install: needs a minor fix to accommodate auto-vivification"
This reverts commit 6576e82e33.

On oddball configs, where the shell key is reused as the gitolite key by
smart( people|-alecks), the ls-remote stops the program dead, preventing
the "git add" and "git commit" that seed the admin repo.

This makes extra work in terms of fixing it after the fact; removing it
makes the install go further, and all you need to do is (1) delete the
first line from ~/.ssh/authorized_keys on the server and (2) back on the
client do a "git clone gitolite:gitolite-admin".

OK so it needs to be removed.  Explaining that was the easy part!  The
hard part is explaining why removing it is harmless.

Look at the commit tree around that commit, and see that the commit
before that (b78a720) was partially reverted in e7e6085.  b78a720
removed the new_repo call from compile, forcing it to happen only on
auth, which forced this workaround for seeding the admin repo.

Since e7e6085 reverted that part of b78a720, giving back new_repo
functions to compile, this line of code wasn't doing any good.  QED and
all that :)
2009-12-30 22:15:58 +05:30
Sitaram Chamarty 79647078a3 auth: regex goof on my part
for those not yet able to upgrade (or until I merge this into the branch
you care about), if you have a repo called, say "bk2git", just refer to
it as "bk2git.git" in the clone command!

[Thanks to Mark Frazer for finding this...]
2009-12-25 01:13:31 +05:30
Sitaram Chamarty d03152316f install transcript 2009-12-25 01:05:21 +05:30
Sitaram Chamarty 1a80f0182d Merge branch 'master' into wildrepos 2009-12-23 20:00:56 +05:30
Sitaram Chamarty b0ce84d47f document @SHELL feature, allow "info" for all,
...but still distinguish shell folks with a small extra line telling
them they have shell access
2009-12-23 19:57:36 +05:30
Sitaram Chamarty 9c3abb20e1 easy install: minor user message change for first-time install 2009-12-22 14:33:47 +05:30
Sitaram Chamarty 203d5690be Merge branch '@all-for-repos' into wildrepos
Conflicts:
	src/gl-compile-conf
2009-12-21 23:02:02 +05:30
Sitaram Chamarty ba3cbd7ecf doc/3, conf: document @all for repos
plus some refactoring of doc/3
2009-12-21 22:58:47 +05:30
Teemu Matilainen f37fb45144 compile: support "repo @all" definitions
"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>
2009-12-21 22:11:21 +05:30
Sitaram Chamarty 03babe7772 parse_acl (gitolite.pm): minor convenience added 2009-12-21 19:59:26 +05:30
Sitaram Chamarty 6fb2296e2c autoviv new repos by user only on "C" access
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")
2009-12-21 19:58:36 +05:30
Sitaram Chamarty 981d693dec Revert "compile, parse_acl: treat foo/CREATER (no regex metas) correctly"
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)
2009-12-21 17:39:33 +05:30
Sitaram Chamarty 6f45f75ca1 minor docfix 2009-12-21 06:23:25 +05:30
Sitaram Chamarty 714e214258 wildrepos: catch-all disclaimer for missing features ;-) 2009-12-20 11:57:53 +05:30
Sitaram Chamarty d49bb6b423 Merge branch 'master' into wildrepos
Conflicts:
	src/gitolite.pm
	src/gl-auth-command
2009-12-20 06:58:33 +05:30
Sitaram Chamarty 2cc19091ca compile: gitolite key as good as shell key for users in @SHELL group
done by inserting a "-s" into the authkey forced command.

(They also lose the "no-pty" restriction, for good measure!)
2009-12-19 22:47:16 +05:30
Sitaram Chamarty 75de6c0438 auth: (WDITOT?) allow special users to get a shell
".../gl-auth-command username" is the normal command that authkeys
forces, and this prevents that key from being used to get a shell.

We now allow the user to get a shell if the forced command has a "-s"
before the "username", like ".../gl-auth-command -s sitaram".

(Now that a plain "ssh gitolite" gets you a shell, there's a new "info"
command that such privileged keys can use to get basic access info).

Thanks to Jesse Keating for the idea!  I can't believe this never
occurred to me before, but I guess I was so enamoured of my "innovation"
in converting what used to be an error into some useful info I didn't
think a bit more :/
2009-12-19 22:47:11 +05:30
Sitaram Chamarty b679bbb56b allow '+' as valid character in user/reponames 2009-12-18 10:15:35 +05:30
Sitaram Chamarty 512fc4a0a5 auth: set umask when autoviv-ing repos
Looks like I'd forgotten this when I did the autoviv code.  Repos
created via gl-compile (when you add a new repo to the config file and
push) worked fine, but repos created via gl-auth (when you autoviv a
repo, wild or not) did not.

This *should* be merged into wildrepos soon after testing; wildrepos
will have a lot more autoviv-ing than master.
2009-12-17 14:11:58 +05:30
Sitaram Chamarty b7404aa772 auth/install/pu-hook: pass ADMINDIR and BINDIR via ENV
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.
2009-12-17 14:11:55 +05:30
Sitaram Chamarty ed2bf526f8 minor docfix 2009-12-13 19:17:18 +05:30
Sitaram Chamarty ecdf6f2350 auth: don't allow literal ".." in reponames
thanks to Teemu for catching this
2009-12-13 12:43:44 +05:30
Sitaram Chamarty 3eb29e17fc allow @ in repo names and patterns
stuff like "repo foo/CREATER/.+" means the reponame has to be a superset
of the username in terms of allowed characters
2009-12-12 10:11:34 +05:30
Sitaram Chamarty a15e910cf8 auth: dont allow trailing slash in reponames...
...like "git clone host:foo/", even if it matches "repo foo/.*"

NOTE: I expect a few more of these special cases to be found as time
goes on and people find new ways to abuse the regex system, whether it
is done intentionally or not.  Anything not fixable by changing the
config file will be fixed in the code asap.

This one, for instance, seems fixable by using "foo/.+" instead of
"foo/.*".  But it actually isn't; the user can do "git clone host:foo//"
and bypass that :(

Still I suspect most situations will get an entry in the "then don't do
that" file :)

----

    patient: "doc, it hurts when I do this"
    doc:     "then don't do that"
2009-12-11 21:37:33 +05:30
Sitaram Chamarty ff28acb059 Merge branch 'master' into wildrepos
master brought in:

  - full email addresses as usernames
  - repo-specific git config

Conflicts:
	doc/3-faq-tips-etc.mkd
	src/gitolite.pm
	src/gl-compile-conf
2009-12-11 11:23:26 +05:30
Sitaram Chamarty 33fc0a7e9f compile, parse_acl: treat foo/CREATER (no regex metas) correctly
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...!
2009-12-11 10:51:37 +05:30
Sitaram Chamarty 780b4cca20 ssh-copy-id workaround detail plus a couple other doc fixes 2009-12-10 17:07:46 +05:30
Sitaram Chamarty 64979c18ea document repo config support 2009-12-09 12:16:22 +05:30
Teemu Matilainen 3403d40d0e Add support for repo configurations
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>
2009-12-09 07:12:01 +05:30
Sitaram Chamarty 38255e4096 merge "allow full email addresses as usernames"
Merge branch 'pu'
2009-12-08 15:14:29 +05:30
Sitaram Chamarty 4441ed82e4 compile: allow full email addresses as usernames
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.
2009-12-08 15:14:05 +05:30
Sitaram Chamarty cdb7245d44 example conf: clarify what @all means
...thanks to Grum for catching this
2009-12-08 13:51:11 +05:30
Teemu Matilainen 5416e38ea8 Fix default configuration paths in documentation
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
2009-12-07 21:04:44 +05:30
Sitaram Chamarty 135079c9d7 minor docfix 2009-12-06 20:40:23 +05:30
Sitaram Chamarty 02cee1d5cf wildrepos: expanded access reporting
This feature has *no* warranty, and so no documentation.  Not more than
this transcript anyway.

config file:

    @prof = u1
    @TAs = u2 u3
    @students = u4 u5 u6

    repo    assignments/CREATER/a[0-9][0-9]
        C   =   @students
        RW+ =   CREATER
        RW  =   WRITERS @TAs
        R   =   READERS @prof

session:

as user "u4":
    # check your permissions
    $ ssh git@server
    PTY allocation request failed on channel 0
    hello u4, the gitolite version here is v0.95-31-gbcb14ca
    you have the following permissions:
     C      assignments/CREATER/a[0-9][0-9]
       @ @  testing
    Connection to localhost closed.

    # autovivify repos for assignment 12 and 24
    $ git clone git@server:assignments/u4/a12 a12
    Initialized empty Git repository in /home/sitaram/t/a12/.git/
    Initialized empty Git repository in /home/gitolite/repositories/assignments/u4/a12.git/
    warning: You appear to have cloned an empty repository.
    $ git clone git@server:assignments/u4/a24 a24
    Initialized empty Git repository in /home/sitaram/t/a24/.git/
    Initialized empty Git repository in /home/gitolite/repositories/assignments/u4/a24.git/
    warning: You appear to have cloned an empty repository.

    # check what repos you autovivified
    $ ssh git@server expand assignments/u4/a[0-9][0-9]
    (u4)    assignments/u4/a12
    (u4)    assignments/u4/a24

as user "u5":
    # check your basic permissions
    $ ssh git@server
    PTY allocation request failed on channel 0
    hello u5, the gitolite version here is v0.95-31-gbcb14ca
    you have the following permissions:
     C      assignments/CREATER/a[0-9][0-9]
       @ @  testing
    Connection to localhost closed.

    # see if you have access to any of u4's repos
    $ ssh git@server expand assignments/u4/a[0-9][0-9]
    # (no output produced)

as user "u4":
    # allow "u5" read access to assignment 12
    # note you type in "R u5", hit enter, then hit Ctrl-D.  Gitolite
    # then produces a confirmation message starting "New perms are:"
    $ ssh git@server setperms assignments/u4/a12
    R u5
    New perms are:
    R u5

as user "u5":
    # again see if you have access to any u4 repos
    $ ssh git@server expand assignments/u4/a[0-9][0-9]
    (u4)    assignments/u4/a12

as user "u4":
    # check what permissions you gave to assignment 12
    $ ssh git@server getperms assignments/u4/a12
    R u5

    # add RW access to "u6" to assignment 12
    # again, type 'em in, then hit Ctrl-D; and note each time you run
    # this you're starting from scratch -- you can't "add to" the
    # permissions.  Deal with it...
    $ ssh git@server setperms assignments/u4/a12
    R u5
    RW u6
    New perms are:
    R u5
    RW u6

as user "u6":
    # check what u4 stuff you have access to
    $ ssh git@server expand assignments/u4/a[0-9][0-9]
    (u4)    assignments/u4/a12
2009-12-06 20:36:16 +05:30
Sitaram Chamarty f620044156 wildrepos: implement getperms and setperms 2009-12-06 20:36:15 +05:30
Sitaram Chamarty 6214ad3ab6 wildrepos: first cut documentation 2009-12-06 20:36:12 +05:30
Sitaram Chamarty f49eddd660 wildrepos: teach auth and update hook about wildcard repos
- 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...
2009-12-06 14:00:21 +05:30
Sitaram Chamarty 77306567e9 wildrepos: teach compile the new syntax
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
2009-12-05 18:42:02 +05:30
Sitaram Chamarty 8a4bb453a0 document that @all doesnt work as expected in deny rules
@all in a deny rule doesnt work as it might look in the config file,
because @all rights are checked last.  This is fine if you dont have any
DENYs (and so rule order doesn't matter), but with DENY it causes some
problems.

I never bothered to document it because I did not expect that any repo
that is "serious" enough to have deny rules *at all* should then allow
*any* kind of "write* access to @all.  That's a very big contradiction
in terms of paranoia!

Translation: this will not be supported.  Don't bother asking.  You know
who you are :)
2009-12-05 14:57:21 +05:30
Sitaram Chamarty e6da853082 auth, compile, pm: good bit of refactoring
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
2009-12-05 14:14:37 +05:30
Sitaram Chamarty c3dbdae134 easy install tail message was apparently too confusing 2009-12-02 11:49:58 +05:30
Sitaram Chamarty a283b8ad49 compile: kill preceding space when killing comments
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)
2009-12-01 22:13:13 +05:30
Sitaram Chamarty e7e6085351 compile: fix description and export-ok problem
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
2009-12-01 21:54:23 +05:30
Sitaram Chamarty d71720d050 fold rebel into master :) [please read]
Well, something even more outrageous than deny rules and path-based
limits came along, so I decided that "rebel" was actually quite
"conformist" in comparision ;-)

Jokes apart, the fact is that the access control rules, even when using
deny rules and path-limits, are still *auditable*.  Which means it is
good enough for "corporate use".

[The stuff that I'm working on now takes away the auditability aspect --
individual users can "own" repos, create rules for themselves, etc.

So let's just say that is the basis of distinguishing "master" now.]
2009-12-01 07:15:05 +05:30
Sitaram Chamarty 498e62c2f3 update hook: allow multiple "refs" to be checked 2009-12-01 05:55:59 +05:30
Sitaram Chamarty e922dfb939 compile: allow PATH/foo and populate the hash correctly 2009-12-01 05:55:59 +05:30
Sitaram Chamarty 601eaf8ea1 tips doc: add pointer to later section on excludes 2009-12-01 05:55:59 +05:30
Sitaram Chamarty 604669ca02 rebel edition -- cos when you need it, you need it bad :-)
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.
2009-12-01 05:55:58 +05:30