Open Stack

Hey,

Just yanking this discussion out of gerrit so it doesn't get lost in a
closed review: https://review.openstack.org/14245

On Wed, 2012-10-10 at 01:55 +0000, Vish Ishaya (Code Review) wrote:

> I like the rewrites of the policy code, but I'm not so sure about this
> addition. Giving too much freedom in the control of policy rules leads
> to inconsistently defined rules. If some policy checks can return
> "roles" to allow for different behaviors then we have some policy
> controls being defined in the policy engine, and some in the how the
> results of the call are used. I can see this leading to a big mess in
> the future.
>
> 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?

Cheers,
Mark.