On Thu, Feb 4, 2010 at 9:38 AM, martin f krafft <madduck@xxxxxxxxxxx> wrote: > also sprach Sitaram Chamarty <sitaram@xxxxxxxxxxx> [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 :) -- 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