Re: [gitolite] repo config for delegated projects

[Sitaram Chamarty <sitaramc@gmail.com>]

On Thu, Feb 4, 2010 at 9:38 AM, martin f krafft <madduck@madduck.net> wrote:
> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1418 +1300]:
>> how about
>>
>>     $DELEGATED_CONFIGS = "hooks.mailinglist,hooks.showrev";
>
> Excellent idea.

OK I've run into a little decision-point here.

The problem above is of making sure that a delegated admin cannot
misuse the gitconfig mechanism to do stuff he's not allowed to do, but
it's actually worse than that :(

First some background.  For a long time I treated the "main" admin
(anyone who has RW/RW+ rights to gitolite.conf) to be eqvt to having
shell access.  Then we started moving away from that, and that is good
because having shell access allows him to bypass the logging that
gitolite does, thus polluting the audit trail.  Preventing that makes
a lot of sense in a corporate environment, and lets you allow a lot
more people to manage the gitolite access list.

Now I just looked up hooks.showrev, and it's supposed to be any shell
command.  Clearly this means anyone who can set that gitconfig option
now has shell capability, and it's game over.

Regardless of how I look at it, I can't think of a cure for this short
of either:
  - putting all the allowed gitconfigs in the RC file, and not in the
config (writing the RC file requires shell access, and we presume the
"root of trust" person has enough smarts to know what to allow and
what not to allow), and allowing repo admins to *refer* to them to use
whichever they want
  - someone coming up with a list of gitconfig's that are "safe", and
specific values for those that are unsafe (like saying "if you use
showrev, you can only use this command  as the value", and forcing
only those.

I'm leaning toward the former; easier for me ;-)  Meanwhile, I'm
punting this to Teemu until the morning fog in my brain clears :)