Open Stack

On Wed, 2012-10-10 at 10:11 -0700, heckj wrote:
> I'm very opposed to changing policy files from declarative policy to
> interpreted mechanisms. There in is the road to madness and horrific
> complexity. I get the desire for wanting to make a seemingly simple
> modification to all "if/else", but it's a slippery slope from there
> into a full-bore interpreted world and internal variables, and the
> last thing we need to do is move into the world of inventing a new
> language (even a DSL) for authorization policies.

Apart from the "case" mechanism, the interpreted string is dead simple,
and was largely designed to be easy for admins to configure; it is
purely an expression syntax (i.e., "role:admin or project_id:%(project_id)s"
instead of the somewhat more opaque [["role:admin", "project_id:%(project_id)s"]]
list-of-lists syntax).  It supports the operators "and", "or", and
"not", and for exactly the reasons you raise, I never intended for it to
be much more complicated than that.  I certainly don't want to see
variables of any sort (can't figure out how *that* would work anyway!).

For reference, the policy file remains a JSON file containing a
dictionary mapping rule names to policies; this just makes it easier for
admins to properly understand and manipulate the rules.  Without this
understanding, who knows what someone could accidentally configure their
policies to do…

>  It should be quite possible and not-too-terrible to create a policy
> that uses simple boolean logic to express this need and keep it
> entirely declarative, especially with the rules mechanism that's
> already in place.

As mentioned, this uses the boolean operators and, or, and not; the
mechanism under discussion right now is the "case" syntax I included,
which allows a "True" return to be split into finer shades.  (And your
other arguments have plenty of bearing on that question, which I'm also
taking seriously, FTR.)

> I would, however, very much like to see a suggestion of roles and
> associated policies that do what Kevin needs as a suggestion for
> deployment. Kevin - how far down the road are you with roles and
> definitions for those roles of what you're doing? I'd love to get the
> layout to document it and include it, along with the current highly
> simplified global-role and come up with some structures that we can
> make available for suggesting how to configure openstack roles and
> policy files that would be useful for a wide variety of use cases.

Honestly, I'm not certain I understand what you're asking here.  I came
up with the "case" mechanism due to a half-remembering of how the user
quotas patch worked, and I figured that could be addressed effectively
that way; I also figured someone might find that functionality useful.
I didn't have specific roles or associated policies in mind.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>