Re: [gitolite] repo config for delegated projects

From: Sitaram Chamarty <sitaram@atc.tcs.com>
Date: Feb 6, 2010, 06:45 UTC
Message-ID: <20100206064523.GA14010@atcmail.atc.tcs.com>
In-Reply-To: <20100206042222.GA7825@lapse.rw.madduck.net>

On Sat, Feb 06, 2010 at 05:22:22PM +1300, martin f krafft wrote:

Show 25 quoted lines

> also sprach Sitaram Chamarty <sitaramc@gmail.com> [2010.02.06.1350 +1300]:
> > 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 :(
> 
> Let me thus challenge the whole delegation mechanism.
> 
> When I first encountered it, I thought it was a great idea, but it
> seems to promise more than it can do. I understand that the reasons
> for that are security-related, and I tip my hat to you for being so
> conscious about this — better have a secure system with limited
> functionality, than an insecure system that can do everything (why
> am I thinking of PHP apps right now???).
> 
> The wildrepos branch is a definite improvement to proper delegation.
> Without it, the main admin has to change the main configuration file
> every time that a delegated admin wants to add a new repo.
> 
> However, given the somewhat awkward configuration (you need to add
> delegated admins in multiple places), and the restrictions, I am
> starting to wonder what use-case delegations solve that couldn't be
> addressed easier with multiple accounts and gitolite instances.
> Thoughts?

In theory, none at all. And if you're not in a corporate environment, having separate accounts and instances is probably easier, as I myself suggest to people sometimes when they need *more* from delegation than what it has now.

What it gives you is *one* central place for all the code, one set of users/ids and one entity to approve new ones, and the means to delegate only the most volatile changes (like at the branch-within-project level), and not the longer term ones like actually adding a new user or a new project (assuming you're not using wildrepos).

It turns out that this is closer to what corporate environments want. I use it, and a few groups in my $DAYJOB also use it, afaik.

But I guess my original question was more for Teemu. As it stands, I need to redo the ability for even the "main" admin to add gitconfigs... it allows him to get a shell too easily.

Show 17 quoted lines

> > 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 think the second path is a red herring. However, I don't
> understand why we would need to go via the RC file instead of the
> main config. Only the main admin can modify that, or appoint others
> to modify it. Plus, it's managed in Git and thus has a history
> attached to it.

That's what I used to think, that it doesn't matter.

But there's a notion (and once I realised it I agreed with it) that the ability to do "shell" things on the server is a step higher than the ability to update gitolite's access list.

Some people needed this, and I agreed. Nothing prevents any installation from giving anyone any rights, but I'd like to prevent them acquiring it via gitolite, even if they can write to the admin repo.

So right now (coming back to the ability to set gitconfig from within gitolite) I'm thinking:

    $GL_GITCONFIG_KEYS = "core.foo core.baz";
        # actually list of regexes for valid keys

and advising people that these are the choices in terms of allowing gitconfig from the admin repo (or delegation; no difference):

  - (ultra paranoid mode): set the variable above to empty;
    no gitconfig allowed from gitolite.conf or delegated
    conf files
  - (just your normal everyday paranoia mode): set the
    variable to stuff that you know will not give shell
    access (example: the aforementioned hooks.mailinglist)
  - ("what, me worry?" mode): set that variable to ".*" and
    allow any damn gitconfig so they won't keep pestering
    you to add a config for them!

In the first 2 cases, someone with shell access must do all required gitconfigs manually on the server when needed.

> Speaking of shell access, I notice gl-auth-command has the -s
> option. Is there a configuration variable that I overlooked which
> allows me to give shell login rights to specific users?

yes; it's in the RC file. If you want to give anyone shell access, add their name to a space-sep list in $SHELL_USERS and push the config once.

The documentation for this is in a weird place (doc/6); sorry about that! Will move it to doc/3 soon.

-- 
Sitaram