On Sat, Feb 06, 2010 at 05:22:22PM +1300, martin f krafft wrote:
> also sprach Sitaram Chamarty <sitaramc@xxxxxxxxx> [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.
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html