cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: [DISCUSS] make the exception, not the rule
Date Wed, 09 Oct 2013 05:08:53 GMT
So I'm saying if you want to disable a command you put myBadCmd=0 in
the  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.


On Tue, Oct 8, 2013 at 5:45 PM, SuichII, Christopher
<> 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
> --
> Chris Suich
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
> On Oct 8, 2013, at 7:11 PM, Prachi Damle <> wrote:
>> I think 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 []
>> Sent: Tuesday, October 08, 2013 3:24 PM
>> To:
>> Subject: [DISCUSS] make the exception, not the rule
>> I would like to largely remove  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
to change the default ACL.  This would make it such that people could add new commands without
the need to edit
>> Thoughts?  How will this play with whatever is being done with rbac?
>> Darren

View raw message