[DISCUSS] make commands.properties the exception, not the rule

[Darren Shepherd <da...@gmail.com>]

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

Re: [DISCUSS] make commands.properties the exception, not the rule

[Darren Shepherd <da...@gmail.com>]

The spring stuff doesn't help.  This discussion didn't really go
anywhere and there weren't much comments.  I'd say at this point we
just put together a proposal.  Give me 5 minutes and I'll throw up a
proposal in a different thread.

Darren

On Thu, Oct 24, 2013 at 1:47 PM, SuichII, Christopher
<Ch...@netapp.com> wrote:
> 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.suich@netapp.com
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
>
> On Oct 9, 2013, at 3:49 PM, SuichII, Christopher <Ch...@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.suich@netapp.com
>> NetApp Software Engineer
>> Data Center Platforms – Cloud Solutions
>> Citrix, Cisco & Red Hat
>>
>> On Oct 9, 2013, at 1:08 AM, Darren Shepherd <da...@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
>>> <Ch...@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.suich@netapp.com
>>>> NetApp Software Engineer
>>>> Data Center Platforms – Cloud Solutions
>>>> Citrix, Cisco & Red Hat
>>>>
>>>> On Oct 8, 2013, at 7:11 PM, Prachi Damle <pr...@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.shepherd@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
>>>>
>>
>

Re: [DISCUSS] make commands.properties the exception, not the rule

["SuichII, Christopher" <Ch...@netapp.com>]

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.suich@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat

On Oct 9, 2013, at 3:49 PM, SuichII, Christopher <Ch...@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.suich@netapp.com
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
> 
> On Oct 9, 2013, at 1:08 AM, Darren Shepherd <da...@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
>> <Ch...@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.suich@netapp.com
>>> NetApp Software Engineer
>>> Data Center Platforms – Cloud Solutions
>>> Citrix, Cisco & Red Hat
>>> 
>>> On Oct 8, 2013, at 7:11 PM, Prachi Damle <pr...@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.shepherd@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
>>> 
> 

Re: [DISCUSS] make commands.properties the exception, not the rule

["SuichII, Christopher" <Ch...@netapp.com>]

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.suich@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat

On Oct 9, 2013, at 1:08 AM, Darren Shepherd <da...@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
> <Ch...@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.suich@netapp.com
>> NetApp Software Engineer
>> Data Center Platforms – Cloud Solutions
>> Citrix, Cisco & Red Hat
>> 
>> On Oct 8, 2013, at 7:11 PM, Prachi Damle <pr...@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.shepherd@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
>> 

Re: [DISCUSS] make commands.properties the exception, not the rule

[Darren Shepherd <da...@gmail.com>]

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
<Ch...@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.suich@netapp.com
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
>
> On Oct 8, 2013, at 7:11 PM, Prachi Damle <pr...@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.shepherd@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
>

Re: [DISCUSS] make commands.properties the exception, not the rule

["SuichII, Christopher" <Ch...@netapp.com>]

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.suich@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat

On Oct 8, 2013, at 7:11 PM, Prachi Damle <pr...@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.shepherd@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

RE: [DISCUSS] make commands.properties the exception, not the rule

[Prachi Damle <Pr...@citrix.com>]

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.shepherd@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

Re: [DISCUSS] make commands.properties the exception, not the rule

[Alena Prokharchyk <Al...@citrix.com>]

On 10/8/13 3:23 PM, "Darren Shepherd" <da...@gmail.com> wrote:

>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
>

Darren, what if admin wants to disable certain API command, how does he do
it with this new approach?