Well, I'm guessing the best way is the contrary, Swann needing to rebase from the change I proposed about policies. The latter is still as draft, committing myself to finish it by today.

-Sylvain

Le 20/11/2013 12:42, Dina Belova a écrit :
I suppose it's ok - just rebase from Swann's commit to have is_admin param to use.


On Wed, Nov 20, 2013 at 3:21 PM, Sylvain Bauza <sylvain.ba...@bull.net <mailto:sylvain.ba...@bull.net>> wrote:

    Hi Yuriy,

    Le 20/11/2013 11:56, Yuriy Taraday a écrit :
    Looking at implementations in Keystone and Nova, I found the only
    use for is_admin but it is essential.

    Whenever in code you need to run a piece of code with admin
    privileges, you can create a new context with  is_admin=True
    keeping all other parameters as is, run code requiring admin
    access and then revert context back.
    My first though was: "Hey, why don't they just add 'admin' role
    then?". But what if in current deployment admin role is named
    like 'TheVerySpecialAdmin'? What if user has tweaked policy.json
    to better suite one's needs?

    So my current understanding is (and I suggest to follow this logic):
    - 'admin' role in context.roles can vary, it's up to cloud admin
    to set necessary value in policy.json;
    - 'is_admin' flag is used to elevate privileges from code and
    it's name is fixed;
    - policy check should assume that user is admin if either special
    role is present or is_admin flag is set.


    Yes indeed, that's something coming into my mind. Looking at Nova,
    I found a "context_is_admin" policy in policy.json allowing you to
    say which role is admin or not [1] and is matched in policy.py
    [2], which itself is called when creating a context [3].

    I'm OK copying that, any objections to it ?


    [1]
    https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L2
    [2] https://github.com/openstack/nova/blob/master/nova/policy.py#L116
    [3]
    https://github.com/openstack/nova/blob/master/nova/context.py#L102

    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org
    <mailto:OpenStack-dev@lists.openstack.org>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to