I’d like to see if we can come up with some solution for this issue. Having ‘add these lines to commands.properties’ is not really an acceptable installation step for plugins/extensions/etc.
So, the ideas I’ve seen are: -Turn commands.properties into a blacklist instead of a whitelist -Dynamically discover additional commands.properties Darren - is there any chance that the Spring modularization stuff you’ve done would make the latter any easier? Are there any others? -Chris -- Chris Suich chris.su...@netapp.com NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat On Oct 9, 2013, at 3:49 PM, SuichII, Christopher <chris.su...@netapp.com> wrote: > I just wanted to add a little clarification from a plugin perspective. > > Having commands.properties as a whitelist just adds another place that > plugins have to register with CloudStack. For plugins that do not intend on > being a part of the CloudStack source, this is actually quite tricky. > Currently, to add entries to commands.properties, any plugin like this would > either need to tell the CS administrator to manually modify this file (error > prone, laborious and an uncommon installation practice) or develop an > installation script to modify commands.properties when installing, updating > or uninstalling the plugin (also error prone and scary). > > -- > Chris Suich > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Oct 9, 2013, at 1:08 AM, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > >> So I'm saying if you want to disable a command you put myBadCmd=0 in >> the commands.properties. So yes, a blacklist over a whitelist. For >> people paranoid about maybe some command exists that they don't know >> about, we can even add a "blacklist=false to the command properties. >> Then the commands.properites becomes the all mighty master of what is >> allowed (a whitelist). But by default, I think the file should be >> empty and default to what is defined by the API annotation. >> >> Darren >> >> On Tue, Oct 8, 2013 at 5:45 PM, SuichII, Christopher >> <chris.su...@netapp.com> wrote: >>> Maybe we could consider switching from a whitelist to a blacklist, then. A >>> whitelist is certainly easier in terms of a one-step configuration, but a >>> blacklist would allow for much easier plugin development, installation and >>> removal. Perhaps we could find write a script that generates the complete >>> list of APIs to create the blacklist from (I know this API exists >>> currently, but not in the format of commands.properties). >>> >>> -- >>> Chris Suich >>> chris.su...@netapp.com >>> NetApp Software Engineer >>> Data Center Platforms – Cloud Solutions >>> Citrix, Cisco & Red Hat >>> >>> On Oct 8, 2013, at 7:11 PM, Prachi Damle <prachi.da...@citrix.com> wrote: >>> >>>> I think commands.properties is not just providing ACL on the API - but it >>>> also serves as a whitelist of APIs available on the deployment. >>>> It can be a one-step configuration option to disable certain functionality. >>>> >>>> Prachi >>>> >>>> >>>> -----Original Message----- >>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >>>> Sent: Tuesday, October 08, 2013 3:24 PM >>>> To: dev@cloudstack.apache.org >>>> Subject: [DISCUSS] make commands.properties the exception, not the rule >>>> >>>> I would like to largely remove commands.properties. I think most API >>>> commands naturally have a default ACL that should be applied. I think it >>>> makes sense to add to the @APICommand flags for user, domain, admin. >>>> Then, as an override mechanism, people can edit commands.properties to >>>> change the default ACL. This would make it such that people could add new >>>> commands without the need to edit commands.properties. >>>> >>>> Thoughts? How will this play with whatever is being done with rbac? >>>> >>>> Darren >>> >
