On Thu, Feb 04, 2010 at 09:22:49AM +1300, martin f krafft wrote:
> Dear Sitaram, dear Teemo, dear gitolite-fans,
>
> src/gl-compile-conf:261 prohibits delegated repositories to make use
> of the functionality to configure config variables of the
> repositories:
>
> die "$WARN $fragment attempting to set repo configuration\n"
> if $fragment ne 'master';
>
> This is a bit unfortunate and makes me reconsider the use of
> delegations.
>
> What is the reason for this restriction?
Like Teemu said, inability to think through all the possible
repurcussions of allowing a delegated admin to set config
variables. There are too many of them for me to go through,
and they'll keep changing.
To recap, what gitolite wants to do is broadly the
following:
- no one who is not admin can do anything to a repo that
the config file does not permit him to do (this is not
affected by the topic of this email; just adding it for
completeness)
- the main admin (who has RW/RW+ access to all of the
gitolite-admin repo) cannot get shell access on the
server. This is a relatively new restriction; initially
I did not think to keep these two privileges separate
- a delegated admin cannot manage any sort of access to
repos that the main admin did not delegate to him.
>
> Are there settings that are potentially compromising?
>
> Would it be worth to consider making it configurable (e.g.
> ~/.gitolite.rc) whether to allow delegated repos to set config
> variables?
I wouldn't mind making it configurable, with the default
being off. Rather than a blanket
$ALLOW_DELEGATE_CONFIGS = 1;
how about
$DELEGATED_CONFIGS = "hooks.mailinglist,hooks.showrev";
(to take Teemu's example config file and the config
variables he uses), so that you (or whoever has shell
access, which is required for changing RC file) can sort of
limit the potential damage.
And the defaults would all be commented out anyway so people
who don't car about this will never have to worry about it.
Regards,
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