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 >
