{"thread":{"id":"22510","subject":"[gitolite] repo config for delegated projects","startedAt":"2010-02-03T20:22:49Z","lastAt":"2010-02-06T18:21:33Z","messageCount":8,"participants":["martin f krafft","Teemu Matilainen","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133519","messageId":"20100203202249.GA27125@lapse.rw.madduck.net","threadId":"22510","inReplyTo":"2e24e5b91002022222h5ca3ebe6k75854a9a056f0ed1@mail.gmail.com","subject":"[gitolite] repo config for delegated projects","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2010-02-03T20:22:49Z","receivedAt":"2010-02-03T20:22:49Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"Dear Sitaram, dear Teemo, dear gitolite-fans,\n\nsrc/gl-compile-conf:261 prohibits delegated repositories to make use\nof the functionality to configure config variables of the\nrepositories:\n\n  die \"$WARN $fragment attempting to set repo configuration\\n\"\n    if $fragment ne 'master';\n\nThis is a bit unfortunate and makes me reconsider the use of\ndelegations.\n\nWhat is the reason for this restriction?\n\nAre there settings that are potentially compromising?\n\nWould it be worth to consider making it configurable (e.g.\n~/.gitolite.rc) whether to allow delegated repos to set config\nvariables?\n\n-- \n .''`.   martin f. krafft <madduck@d.o>      Related projects:\n: :'  :  proud Debian developer               http://debiansystem.info\n`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org\n  `-  Debian - when you have better things to do than fixing systems\n \n\"there are two major products that come out of berkeley: lsd and unix.\"\n one caused me an addiction\n                                                             -- fyodor\n"},{"id":"133550","messageId":"20100203224734.GI4808@reaktor.fi","threadId":"22510","inReplyTo":"20100203202249.GA27125@lapse.rw.madduck.net","subject":"Re: [gitolite] repo config for delegated projects","fromName":"Teemu Matilainen","fromEmail":"teemu.matilainen@iki.fi","sentAt":"2010-02-03T22:47:34Z","receivedAt":"2010-02-03T22:47:34Z","isPatch":false,"sender":{"key":"teemu.matilainen@iki.fi","avatar":"https://avatars.githubusercontent.com/u/79116?v=4"},"body":"On Thu, 04 Feb 2010, martin f krafft wrote:\n\n> src/gl-compile-conf:261 prohibits delegated repositories to make use\n> of the functionality to configure config variables of the\n> repositories:\n> \n>   die \"$WARN $fragment attempting to set repo configuration\\n\"\n>     if $fragment ne 'master';\n> \n> This is a bit unfortunate and makes me reconsider the use of\n> delegations.\n> \n> What is the reason for this restriction?\n\nWell, the main reason probably is that I don't personally use delegation\nand got tired of even thinking about the security concerns. =)\n\n> Are there settings that are potentially compromising?\n\nI think it depends on the setup and especially hooks.\nCan't come up with any real problem, though.\n\n> Would it be worth to consider making it configurable (e.g.\n> ~/.gitolite.rc) whether to allow delegated repos to set config\n> variables?\n\nThat's Sitaram's call. :)\n\n\n-- \n\t- Teemu\n"},{"id":"133565","messageId":"20100204011842.GB497@atcmail.atc.tcs.com","threadId":"22510","inReplyTo":"20100203202249.GA27125@lapse.rw.madduck.net","subject":"Re: [gitolite] repo config for delegated projects","fromName":"Sitaram Chamarty","fromEmail":"sitaram@atc.tcs.com","sentAt":"2010-02-04T01:18:42Z","receivedAt":"2010-02-04T01:18:42Z","isPatch":false,"sender":{"key":"sitaram@atc.tcs.com","avatar":null},"body":"On Thu, Feb 04, 2010 at 09:22:49AM +1300, martin f krafft wrote:\n> Dear Sitaram, dear Teemo, dear gitolite-fans,\n> \n> src/gl-compile-conf:261 prohibits delegated repositories to make use\n> of the functionality to configure config variables of the\n> repositories:\n> \n>   die \"$WARN $fragment attempting to set repo configuration\\n\"\n>     if $fragment ne 'master';\n> \n> This is a bit unfortunate and makes me reconsider the use of\n> delegations.\n> \n> What is the reason for this restriction?\n\nLike Teemu said, inability to think through all the possible\nrepurcussions of allowing a delegated admin to set config\nvariables.  There are too many of them for me to go through,\nand they'll keep changing.\n\nTo recap, what gitolite wants to do is broadly the\nfollowing:\n\n  - no one who is not admin can do anything to a repo that\n    the config file does not permit him to do (this is not\n    affected by the topic of this email; just adding it for\n    completeness)\n\n  - the main admin (who has RW/RW+ access to all of the\n    gitolite-admin repo) cannot get shell access on the\n    server.  This is a relatively new restriction; initially\n    I did not think to keep these two privileges separate\n\n  - a delegated admin cannot manage any sort of access to\n    repos that the main admin did not delegate to him.\n\n> \n> Are there settings that are potentially compromising?\n> \n> Would it be worth to consider making it configurable (e.g.\n> ~/.gitolite.rc) whether to allow delegated repos to set config\n> variables?\n\nI wouldn't mind making it configurable, with the default\nbeing off.  Rather than a blanket\n\n    $ALLOW_DELEGATE_CONFIGS = 1;\n\nhow about\n\n    $DELEGATED_CONFIGS = \"hooks.mailinglist,hooks.showrev\";\n\n(to take Teemu's example config file and the config\nvariables he uses), so that you (or whoever has shell\naccess, which is required for changing RC file) can sort of\nlimit the potential damage.\n\nAnd the defaults would all be commented out anyway so people\nwho don't car about this will never have to worry about it.\n\nRegards,\n\nSitaram\n"},{"id":"133582","messageId":"20100204040812.GC13411@lapse.rw.madduck.net","threadId":"22510","inReplyTo":"20100204011842.GB497@atcmail.atc.tcs.com","subject":"Re: [gitolite] repo config for delegated projects","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2010-02-04T04:08:12Z","receivedAt":"2010-02-04T04:08:12Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1418 +1300]:\n> how about\n> \n>     $DELEGATED_CONFIGS = \"hooks.mailinglist,hooks.showrev\";\n\nExcellent idea.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \nnow I lay me back to sleep.\nthe speaker's dull; the subject's deep.\nif he should stop before I wake,\ngive me a nudge for goodness' sake.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"133767","messageId":"2e24e5b91002051650k3c7cf14ev8752d36b5616e9a4@mail.gmail.com","threadId":"22510","inReplyTo":"20100204040812.GC13411@lapse.rw.madduck.net","subject":"Re: [gitolite] repo config for delegated projects","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2010-02-06T00:50:50Z","receivedAt":"2010-02-06T00:50:50Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Thu, Feb 4, 2010 at 9:38 AM, martin f krafft <madduck@madduck.net> wrote:\n> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1418 +1300]:\n>> how about\n>>\n>>     $DELEGATED_CONFIGS = \"hooks.mailinglist,hooks.showrev\";\n>\n> Excellent idea.\n\nOK I've run into a little decision-point here.\n\nThe problem above is of making sure that a delegated admin cannot\nmisuse the gitconfig mechanism to do stuff he's not allowed to do, but\nit's actually worse than that :(\n\nFirst some background.  For a long time I treated the \"main\" admin\n(anyone who has RW/RW+ rights to gitolite.conf) to be eqvt to having\nshell access.  Then we started moving away from that, and that is good\nbecause having shell access allows him to bypass the logging that\ngitolite does, thus polluting the audit trail.  Preventing that makes\na lot of sense in a corporate environment, and lets you allow a lot\nmore people to manage the gitolite access list.\n\nNow I just looked up hooks.showrev, and it's supposed to be any shell\ncommand.  Clearly this means anyone who can set that gitconfig option\nnow has shell capability, and it's game over.\n\nRegardless of how I look at it, I can't think of a cure for this short\nof either:\n  - putting all the allowed gitconfigs in the RC file, and not in the\nconfig (writing the RC file requires shell access, and we presume the\n\"root of trust\" person has enough smarts to know what to allow and\nwhat not to allow), and allowing repo admins to *refer* to them to use\nwhichever they want\n  - someone coming up with a list of gitconfig's that are \"safe\", and\nspecific values for those that are unsafe (like saying \"if you use\nshowrev, you can only use this command  as the value\", and forcing\nonly those.\n\nI'm leaning toward the former; easier for me ;-)  Meanwhile, I'm\npunting this to Teemu until the morning fog in my brain clears :)\n"},{"id":"133776","messageId":"20100206042222.GA7825@lapse.rw.madduck.net","threadId":"22510","inReplyTo":"2e24e5b91002051650k3c7cf14ev8752d36b5616e9a4@mail.gmail.com","subject":"Re: [gitolite] repo config for delegated projects","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2010-02-06T04:22:22Z","receivedAt":"2010-02-06T04:22:22Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Sitaram Chamarty <sitaramc@gmail.com> [2010.02.06.1350 +1300]:\n> OK I've run into a little decision-point here.\n> \n> The problem above is of making sure that a delegated admin cannot\n> misuse the gitconfig mechanism to do stuff he's not allowed to do,\n> but it's actually worse than that :(\n\nLet me thus challenge the whole delegation mechanism.\n\nWhen I first encountered it, I thought it was a great idea, but it\nseems to promise more than it can do. I understand that the reasons\nfor that are security-related, and I tip my hat to you for being so\nconscious about this — better have a secure system with limited\nfunctionality, than an insecure system that can do everything (why\nam I thinking of PHP apps right now???).\n\nThe wildrepos branch is a definite improvement to proper delegation.\nWithout it, the main admin has to change the main configuration file\nevery time that a delegated admin wants to add a new repo.\n\nHowever, given the somewhat awkward configuration (you need to add\ndelegated admins in multiple places), and the restrictions, I am\nstarting to wonder what use-case delegations solve that couldn't be\naddressed easier with multiple accounts and gitolite instances.\nThoughts?\n\n> Regardless of how I look at it, I can't think of a cure for this short\n> of either:\n>   - putting all the allowed gitconfigs in the RC file, and not in the\n> config (writing the RC file requires shell access, and we presume the\n> \"root of trust\" person has enough smarts to know what to allow and\n> what not to allow), and allowing repo admins to *refer* to them to use\n> whichever they want\n>   - someone coming up with a list of gitconfig's that are \"safe\", and\n> specific values for those that are unsafe (like saying \"if you use\n> showrev, you can only use this command  as the value\", and forcing\n> only those.\n\nI think the second path is a red herring. However, I don't\nunderstand why we would need to go via the RC file instead of the\nmain config. Only the main admin can modify that, or appoint others\nto modify it. Plus, it's managed in Git and thus has a history\nattached to it.\n\nSpeaking of shell access, I notice gl-auth-command has the -s\noption. Is there a configuration variable that I overlooked which\nallows me to give shell login rights to specific users?\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \nreview of a chemistry paper:\n  \"paper should be greatly reduced or completely oxidized.\"\n                                                    -- frank vastola\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"133781","messageId":"20100206064523.GA14010@atcmail.atc.tcs.com","threadId":"22510","inReplyTo":"20100206042222.GA7825@lapse.rw.madduck.net","subject":"Re: [gitolite] repo config for delegated projects","fromName":"Sitaram Chamarty","fromEmail":"sitaram@atc.tcs.com","sentAt":"2010-02-06T06:45:23Z","receivedAt":"2010-02-06T06:45:23Z","isPatch":false,"sender":{"key":"sitaram@atc.tcs.com","avatar":null},"body":"On Sat, Feb 06, 2010 at 05:22:22PM +1300, martin f krafft wrote:\n> also sprach Sitaram Chamarty <sitaramc@gmail.com> [2010.02.06.1350 +1300]:\n> > OK I've run into a little decision-point here.\n> > \n> > The problem above is of making sure that a delegated admin cannot\n> > misuse the gitconfig mechanism to do stuff he's not allowed to do,\n> > but it's actually worse than that :(\n> \n> Let me thus challenge the whole delegation mechanism.\n> \n> When I first encountered it, I thought it was a great idea, but it\n> seems to promise more than it can do. I understand that the reasons\n> for that are security-related, and I tip my hat to you for being so\n> conscious about this — better have a secure system with limited\n> functionality, than an insecure system that can do everything (why\n> am I thinking of PHP apps right now???).\n> \n> The wildrepos branch is a definite improvement to proper delegation.\n> Without it, the main admin has to change the main configuration file\n> every time that a delegated admin wants to add a new repo.\n> \n> However, given the somewhat awkward configuration (you need to add\n> delegated admins in multiple places), and the restrictions, I am\n> starting to wonder what use-case delegations solve that couldn't be\n> addressed easier with multiple accounts and gitolite instances.\n> Thoughts?\n\nIn theory, none at all.  And if you're not in a corporate\nenvironment, having separate accounts and instances is\nprobably easier, as I myself suggest to people sometimes\nwhen they need *more* from delegation than what it has now.\n\nWhat it gives you is *one* central place for all the code,\none set of users/ids and one entity to approve new ones, and\nthe means to delegate only the most volatile changes (like\nat the branch-within-project level), and not the longer term\nones like actually adding a new user or a new project\n(assuming you're not using wildrepos).\n\nIt turns out that this is closer to what corporate\nenvironments want.  I use it, and a few groups in my $DAYJOB\nalso use it, afaik.\n\nBut I guess my original question was more for Teemu.  As it\nstands, I need to redo the ability for even the \"main\" admin\nto add gitconfigs... it allows him to get a shell too\neasily.\n\n> > Regardless of how I look at it, I can't think of a cure for this short\n> > of either:\n> >   - putting all the allowed gitconfigs in the RC file, and not in the\n> > config (writing the RC file requires shell access, and we presume the\n> > \"root of trust\" person has enough smarts to know what to allow and\n> > what not to allow), and allowing repo admins to *refer* to them to use\n> > whichever they want\n> >   - someone coming up with a list of gitconfig's that are \"safe\", and\n> > specific values for those that are unsafe (like saying \"if you use\n> > showrev, you can only use this command  as the value\", and forcing\n> > only those.\n> \n> I think the second path is a red herring. However, I don't\n> understand why we would need to go via the RC file instead of the\n> main config. Only the main admin can modify that, or appoint others\n> to modify it. Plus, it's managed in Git and thus has a history\n> attached to it.\n\nThat's what I used to think, that it doesn't matter.\n\nBut there's a notion (and once I realised it I agreed with\nit) that the ability to do \"shell\" things on the server is a\nstep higher than the ability to update gitolite's access\nlist.\n\nSome people needed this, and I agreed.  Nothing prevents any\ninstallation from giving anyone any rights, but I'd like to\nprevent them acquiring it via gitolite, even if they can\nwrite to the admin repo.\n\nSo right now (coming back to the ability to set gitconfig\nfrom within gitolite) I'm thinking:\n\n    $GL_GITCONFIG_KEYS = \"core.foo core.baz\";\n        # actually list of regexes for valid keys\n\nand advising people that these are the choices in terms of\nallowing gitconfig from the admin repo (or delegation; no\ndifference):\n\n  - (ultra paranoid mode): set the variable above to empty;\n    no gitconfig allowed from gitolite.conf or delegated\n    conf files\n  - (just your normal everyday paranoia mode): set the\n    variable to stuff that you know will not give shell\n    access (example: the aforementioned hooks.mailinglist)\n  - (\"what, me worry?\" mode): set that variable to \".*\" and\n    allow any damn gitconfig so they won't keep pestering\n    you to add a config for them!\n\nIn the first 2 cases, someone with shell access must do all\nrequired gitconfigs manually on the server when needed.\n\n> Speaking of shell access, I notice gl-auth-command has the -s\n> option. Is there a configuration variable that I overlooked which\n> allows me to give shell login rights to specific users?\n\nyes; it's in the RC file.  If you want to give anyone shell\naccess, add their name to a space-sep list in $SHELL_USERS\nand push the config once.\n\nThe documentation for this is in a weird place (doc/6);\nsorry about that!  Will move it to doc/3 soon.\n\n-- \nSitaram\n"},{"id":"133815","messageId":"20100206182133.GL2530@reaktor.fi","threadId":"22510","inReplyTo":"2e24e5b91002051650k3c7cf14ev8752d36b5616e9a4@mail.gmail.com","subject":"Re: [gitolite] repo config for delegated projects","fromName":"Teemu Matilainen","fromEmail":"teemu.matilainen@iki.fi","sentAt":"2010-02-06T18:21:33Z","receivedAt":"2010-02-06T18:21:33Z","isPatch":false,"sender":{"key":"teemu.matilainen@iki.fi","avatar":"https://avatars.githubusercontent.com/u/79116?v=4"},"body":"On Sat, 06 Feb 2010, Sitaram Chamarty wrote:\n\n> Now I just looked up hooks.showrev, and it's supposed to be any shell\n> command.  Clearly this means anyone who can set that gitconfig option\n> now has shell capability, and it's game over.\n\nBut of course you need to have a hook that runs the command.  And\nsetting hooks requires shell access.\n\nSorry for not thinking any problems with the config thing.  I personally\ndon't use the delegation and on the other hand all our gitolite\nadministrators anyway have shell access to the server...\n\n> Regardless of how I look at it, I can't think of a cure for this short\n> of either:\n>   - putting all the allowed gitconfigs in the RC file, and not in the\n> config (writing the RC file requires shell access, and we presume the\n> \"root of trust\" person has enough smarts to know what to allow and\n> what not to allow), and allowing repo admins to *refer* to them to use\n> whichever they want\n\nThis sounds better solution for me.\n\n>   - someone coming up with a list of gitconfig's that are \"safe\", and\n> specific values for those that are unsafe (like saying \"if you use\n> showrev, you can only use this command  as the value\", and forcing\n> only those.\n\nMight get too complicated.  Anyway the person setting the hook script\nshould know what it does and which configuration keys it uses and how.\n\n\n-- \n\t- Teemu\n"}]}