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? > 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. 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? -- martin | http://madduck.net/ | http://two.sentenc.es/ review of a chemistry paper: "paper should be greatly reduced or completely oxidized." -- frank vastola spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)