Commit graph

209 commits

Author SHA1 Message Date
Sitaram Chamarty c8d4aef460 compile: allow "#" in *simple* strings
like: config notify.ircChannel = "#foo"

(thanks, jhelwig)
2010-01-23 16:56:04 +05:30
Sitaram Chamarty e68d76f127 doc/6 revamp; would appreciate reviews ;-) 2010-01-22 20:28:35 +05:30
Sitaram Chamarty 645ab77af5 compile: disallow multiple pubkeys in one file
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.
2010-01-17 16:31:47 +05:30
Sitaram Chamarty 261b289609 mention NAME-based restrictions in README 2010-01-15 10:40:07 +05:30
Sitaram Chamarty d61890301f delegation doc: minor oops
I know hardly anyone is using delegation, but if you find yourself
locked out from pushing because of this one little thing, do this:

  * on your gitolite-admin clone, add the required lines per this patch,
    and commit

  * on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and
    delete the following line

        'NAME_LIMITS' => 1

    from the entry for "gitolite-admin" (if you don't know what that
    means delete *all* such lines) and save the file

  * back on your admin repo clone, do a push
2010-01-15 10:18:33 +05:30
Sitaram Chamarty ecfd20e793 @SHELL is now $SHELL_USERS in the rc file (warning: backward compat breakage)
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
2010-01-14 19:35:46 +05:30
Sitaram Chamarty a9824464e5 update hook: anchor refex with ^ when matching refs
Currently, a line like

    RW  foo =   user1

allows user1 to push any ref that contains the string refs/heads/foo.
This includes refs like

    refs/heads/foo
    refs/heads/foobar
    refs/heads/foo/bar

which is fine; that is what is intended.  (You can always use foo$
instead of foo if you want to prevent the latter two).

Similarly,

    RW  refs/foo    =   user1

allows

    refs/foo
    refs/foobar
    refs/foo/bar

Now, I don't see this as a "security risk" but the fact is that this
allows someone to clutter your repo with junk like

    refs/bar/refs/heads/foo
    refs/heads/bar/refs/heads/foo

(or, with the second config line example,

    refs/bar/refs/foo
    refs/heads/bar/refs/foo
)

My personal advice is if you find someone doing that intentionally, you
should probably take him out and shoot him [*], but since now *two*
people have complained about this, here goes...

----

[*]     you don't have to take him out if you don't want to
2010-01-13 15:17:55 +05:30
Teemu Matilainen 6c38e30e9a compile: support "include" definition
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>
2010-01-10 09:50:20 +05:30
Sitaram Chamarty 839027f7a7 change delegation to NAME/ style (warning: backward compat breakage)
This is a backward incompatible change.  If you are using delegation and
you upgrade to this version, please do the following:

  * change your gitolite.conf file to use the new syntax (see
    doc/5-delegation.mkd in this commit)

  * for each branch "foo" in the gitolite-admin repo, do this:

        # (on "master" branch)
        git checkout foo -- conf/fragments/foo.conf

  * git add all those new fragments and commit to master

  * delete all the branches on your clone and the server

        # again, for each branch foo
        git branch -D foo
        git push origin :foo
2010-01-10 09:50:08 +05:30
Sitaram Chamarty 08ef3555a1 deprecation warning about old style PATH/ syntax
(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
2010-01-09 20:31:07 +05:30
Sitaram Chamarty 7124faa9f3 NAME-based restrictions
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.
2010-01-09 20:30:53 +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 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 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 6f45f75ca1 minor docfix 2009-12-21 06:23:25 +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 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 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
Sitaram Chamarty bfc3b6cd58 example conf: clarify group name parsing 2009-11-30 07:00:31 +05:30
Sitaram Chamarty 81911b77cc new repo autovivified now
Merge branch 'pu'
2009-11-28 17:42:55 +05:30
Sitaram Chamarty 6576e82e33 easy install: needs a minor fix to accommodate auto-vivification 2009-11-27 23:57:03 +05:30
Sitaram Chamarty b78a720cee auth/compile: auto-vivify is default now, so:
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!)
2009-11-27 23:06:48 +05:30
Sitaram Chamarty c3b5e3b1af compile, pm: factor out new repo creation
...also wrap_chdir, wrap_open, $ABRT, and $WARN
2009-11-27 23:06:47 +05:30
Sitaram Chamarty 5696b13f62 Merge branch 'gitweb-owner' 2009-11-27 13:52:34 +05:30
Sitaram Chamarty d8cb62934f docs: document how to specify "owner" for gitweb 2009-11-27 13:47:33 +05:30
Sitaram Chamarty d2a053ba3c compile: add owner field in the same line as the gitweb descriptions
this goes into the project list
2009-11-27 13:23:48 +05:30