Commit graph

59 commits

Author SHA1 Message Date
Sitaram Chamarty 9d0a208b26 (adc) auth: git-init subcommand added
The "fork" adc cannot simply do a "git clone..."; hooks and gl-creater
won't get set up.  We need a way to initiate the *creation* of a repo
from a shell command, and then fetch the refs over.

For a long time, we used to trick gitolite into creating a repo for us
by simply using "git ls-remote host:reponame" ;-)  Now we have an actual
command, so we can say "ssh git@server git-init \'reponame\'"

Yes; those single quotes are required.  Deal with it.
2010-04-25 13:21:16 +05:30
Sitaram Chamarty 567e70ba40 (adc) admin-defined commands
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
2010-04-25 13:21:16 +05:30
Sitaram Chamarty 6be0946aee (rrq) gl-auth-command uses new repo_rights sub 2010-04-25 13:21:15 +05:30
Sitaram Chamarty 90e141cd61 (rrq) refactor all the rights querying
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
2010-04-25 13:21:15 +05:30
Sitaram Chamarty 34aad34478 make "expand" also print version, like "info" does
(thanks to Ilari for catching this)
2010-04-16 19:23:18 +05:30
Sitaram Chamarty 72b63abaf2 auth, gitolite.pm: do not leak info about repo existence
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!
2010-03-29 21:18:39 +05:30
Sitaram Chamarty a45d2d9912 auth: do not implicitly assign RW access for creaters
a configuration like this:

    repo CREATER/.*
        C       =   CREATER
        RW+     =   WRITERS

was buggy; CREATER was implicitly part of WRITERS so he got RW
permissions implicitly, so the push went through
2010-03-27 22:55:58 +05:30
Sitaram Chamarty 7bfb3676b7 @all for repos is now much cleaner; a true @all...
- 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.
2010-03-26 21:36:05 +05:30
Sitaram Chamarty 6dbaa0d325 auth: expand etc. *may* have single-quotes around reponame 2010-03-01 20:34:25 +05:30
Teemu Matilainen deda3da182 auth: do not anchor the pattern given for expand
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>
2010-02-27 12:30:39 +05:30
Sitaram Chamarty ea123bbfb4 Merge branch 'dps' into master
Conflicts:
	doc/0-INSTALL.mkd
2010-02-25 20:28:02 +05:30
Sitaram Chamarty 1de9e963f0 auth: behave better when no argument supplied to wild commands
expand gets a default '.*' argument
others die with an error message
2010-02-18 19:20:46 +05:30
Sitaram Chamarty 74d70e3b9f move hooks out of src
src/hooks is now hooks/common
src/ga... is now hooks/gitolite-admin/post-update
2010-02-13 13:02:24 +05:30
Sitaram Chamarty 65b8c0c48a make $bindir absolute 2010-02-13 13:02:21 +05:30
Sitaram Chamarty 388f4d873d (IMPORTANT; read this in full) no more "wildrepos"
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).
2010-02-07 13:22:43 +05:30
Sitaram Chamarty fc0b627f55 Merge branch 'master' into wildrepos
Conflicts:
	src/gitolite.pm
2010-02-05 07:05:43 +05:30
Sitaram Chamarty 767657c187 Merge teemu/topic/wildrepo_description_and_owner into wildrepos 2010-02-05 06:32:30 +05:30
Teemu Matilainen fa65d719a8 Enable setting desription for wildrepos
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>
2010-02-05 06:32:04 +05:30
Sitaram Chamarty 86166f7adc $shell_allowed needs to be passed to specal_cmds
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
2010-02-04 15:25:22 +05:30
Sitaram Chamarty c43560d2ef Merge branch 'master' into wildrepos
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
2010-02-04 14:42:10 +05:30
Sitaram Chamarty 67c10a34fe auth: new subcommand "htpasswd"
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)
2010-02-04 11:55:24 +05:30
Sitaram Chamarty 2d9c4c4ae9 oops; logging bug 2010-02-01 16:54:39 +05:30
Sitaram Chamarty 43da598c08 auth: minor flow change when defaulting to "info" 2010-02-01 15:59:03 +05:30
Sitaram Chamarty 98a4c79dce (read this in full) access control for non-git commands running over ssh
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.
2010-02-01 11:49:21 +05:30
Sitaram Chamarty 17c8075de7 Merge branch 'master' into wildrepos
factor out log_it and check_ref; update hook now requires gitolite.pm

Conflicts:
	src/hooks/update
2010-02-01 11:00:44 +05:30
Sitaram Chamarty 0b960cfae2 auth/update-hook/pm: make &log() a common function 2010-02-01 10:52:55 +05:30
Sitaram Chamarty 4142be4e59 auth: reporting changes for wildcard-created repos
- 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.
2010-01-29 16:37:34 +05:30
Sitaram Chamarty bede47e2db Merge branch 'master' into wildrepos
Conflicts:
	src/hooks/update
2010-01-14 20:47:04 +05:30
Teemu Matilainen 15475f666c Fix exit codes for allowed ssh commands
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>
2010-01-10 11:24:57 +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 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 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 d49bb6b423 Merge branch 'master' into wildrepos
Conflicts:
	src/gitolite.pm
	src/gl-auth-command
2009-12-20 06:58:33 +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 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 ecdf6f2350 auth: don't allow literal ".." in reponames
thanks to Teemu for catching this
2009-12-13 12:43:44 +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 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 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 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 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 9a85f5d0d6 auth: print permissions for @all also
I don't have a use for "@all" at all (pun not intended!) other than the
"testing" repo, but <teemu dot matilainen at iki dot fi> sent in a patch
to mark those repos with "R" and "W" in the permissions list, and I
started thinking about it.

This could actually be useful if we *differentiated* such access from
normal (explicit username) access.  From the "corporate environment"
angle, it would be nice if a project manager could quickly check if any
of his projects have erroneously been made accessible by @all.

So what we do now is print "@" in the corresponding column if "@all" has
the corresponding access.

Also, when someone has access both as himself *and* via @all, we print
the "@"; printing the "R" or "W" would hide the "@", and wouldn't
correctly satisfy the use case described above.
2009-11-25 09:15:36 +05:30
Sitaram Chamarty de2e38c372 minor doc/message updates/clarifications 2009-11-24 09:16:29 +05:30
Sitaram Chamarty 648dce20ec auth: make ".git" at the end optional 2009-10-30 10:37:02 +05:30
Sitaram Chamarty a19a7f01d7 auth, doc/3: print useful information when no command given 2009-10-28 21:46:57 +05:30
Sitaram Chamarty 78d02e1437 the rc file can now be in one of 2 places...
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.
2009-10-25 12:45:45 +05:30
Sitaram Chamarty 59e15e62a1 support git installed outside default $PATH
(also some minor fixes to doc/3)
2009-10-13 10:03:12 +05:30