[openstack-dev] [Keystone] policy has no effect because of hard coded assert_admin?

Dolph Mathews dolph.mathews at gmail.com
Thu Dec 12 22:43:00 UTC 2013


On Thu, Dec 12, 2013 at 12:40 PM, Morgan Fainberg <m at metacloud.com> wrote:

> As Dolph stated, V3 is where the policy file protects.  This is one of the
> many reasons why I would encourage movement to using V3 Keystone over V2.
>
> The V2 API is officially deprecated in the Icehouse cycle, I think that
> moving the decorator potentially could cause more issues than not as stated
> for compatibility.  I would be very concerned about breaking compatibility
> with deployments and maintaining the security behavior with the
> encouragement to move from V2 to V3.  I am also not convinced passing the
> context down to the manager level is the right approach.  Making a move on
> where the protection occurs likely warrants a deeper discussion (perhaps in
> Atlanta?).
>

++ I *should* have written "could be moved to the manager layer." I don't
actually think they should, at least at the moment. With v2.0 gone, it
would be a more interesting, more approachable discussion.


>
> Cheers,
> Morgan Fainberg
>
> On December 12, 2013 at 10:32:40, Dolph Mathews (dolph.mathews at gmail.com<//dolph.mathews at gmail.com>)
> wrote:
>
> The policy file is protecting v3 API calls at the controller layer, but
> you're calling the v2 API. The policy decorators should be moved to the
> manager layer to protect both APIs equally... but we'd have to be very
> careful not to break deployments depending on the trivial "assert_admin"
> behavior (hence the reason we only wrapped v3 with the new policy
> decorators).
>
>
> On Thu, Dec 12, 2013 at 1:41 AM, Qiu Yu <unicell at gmail.com> wrote:
>
>>  Hi,
>>
>> I was trying to fine tune some keystone policy rules. Basically I want to
>> grant "create_project" action to user in "ops" role. And following are my
>> steps.
>>
>> 1. Adding a new user "usr1"
>> 2. Creating new role "ops"
>> 3. Granting this user a "ops" role in "service" tenant
>> 4. Adding new lines to keystone policy file
>>
>>          "ops_required": [["role:ops"]],
>>         "admin_or_ops": [["rule:admin_required"], ["rule:ops_required"]],
>>
>> 5. Change
>>
>>         "identity:create_project": [["rule:admin_required"]],
>>     to
>>         "identity:create_project": [["rule:admin_or_ops"]],
>>
>> 6. Restart keystone service
>>
>> keystone tenant-create with credential of user "usr1" still returns 403
>> Forbidden error.
>> “You are not authorized to perform the requested action, admin_required.
>> (HTTP 403)”
>>
>> After some quick scan, it seems that create_project function has a
>> hard-coded assert_admin call[1], which does not respect settings in the
>> policy file.
>>
>> Any ideas why? Is it a bug to fix? Thanks!
>> BTW, I'm running keystone havana release with V2 API.
>>
>> [1]
>> https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L105
>>
>> Thanks,
>> --
>> Qiu Yu
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> -Dolph
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/579469ed/attachment.html>


More information about the OpenStack-dev mailing list