Open Stack

On Wed, 2012-10-10 at 14:45 +0100, Mark McLoughlin wrote:
> > I think the policy implementation is clearer when every complex policy
> > decision is "denormalized" into one action and one target with a
> > simple true-false response. If you want some roles to be able to (for
> > example) modify a specific field, then there should be an action for
> > modifying that particular field. Otherwise I think the policy will
> > become overly complex and hard to follow.
> 
> That seems like a good point. I admit that I didn't pay enough attention
> to how this would actually be used.
> 
> In the docs, Kevin says:
> 
>   Consider a function that not only wants to check whether a user is
>   allowed to modify an object, but wants to see which set of fields the
>   user is allowed to modify.  For this, we can use the new "case"
>   expression::
> 
>       case {
>         "fulladmin" = role:admin;
>         "projectadmin" = project_id:%(project_id)s and role:projectadmin
>       }
> 
> If we take a specific example of admin_actions:pause, this would allow
> the rule to not just say "the action is allowed" but also "the action is
> allowed because the user is a full admin" or "the user is a project
> admin".
> 
> The question then would be, what does nova do with that info? And if
> nova might make a decision that something is allowed for "fulladmin" but
> not "projectadmin", then why aren't they not two separate rules in the
> policy? By hard-coding the "full vs project admin" decision in Nova, it
> means it's not configurable in the policy.
> 
> Kevin - maybe you could elaborate more on the specific use case?

The specific case I had in mind was a hypothetical case where an API
update method allows all fields to be updated for admin users but only
some fields to be updated for project admins.  For instance, maybe a
full admin can change which project the object belongs to as well as
some limit, while a project admin should only be able to alter the
limit.  I believe this was one element of the (now reverted) user quotas
patch, which ended up having quota keys
"compute_extension:quotas:update_admin" and
"compute_extension:quotas:update_project_admin".

In my opinion, there is some merit to the desire to keep policies
simple, i.e., true-false decision making; but I fear we could end up
with an explosion of policy rules like those the user quotas patch
added, which I believe will make the policy files harder to understand
as we enhance nova.   I (obviously :) feel that having the "case"
enhancement strikes a good balance between the two extremes here.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>