yahoo-eng-team team mailing list archive

[Timothy Symanczyk <timothy_symanczyk@xxxxxxxxxxxx>]

Public bug reported:

Found this bug in kilo, but have confirmed that it can still be
reproduced with a fresh install of master branch as of today.

To reproduce the bad behaviour :

1) Retrieve an unscoped token for any valid account.

2) Using curl - invoke list_user_projects for the SAME user from step 1
using the token from step 1, and observe that this works as expected.

3) Alter the in-use policy file by inserting "role:service or " at the beginning of the rule for list_user_projects ...
<     "identity:list_user_projects": "role:service or rule:admin_or_owner",
---
>     "identity:list_user_projects": "rule:admin_or_owner",
.... Note that the addition of this 'or' clause should not be able to logically cause any additional denials. 

4) Try the identical curl command from step 2 again, and observe that it
now fails with 403 Forbidden.

** Affects: keystone
     Importance: Undecided
     Assignee: Timothy Symanczyk (timothy-symanczyk)
         Status: New

** Changed in: keystone
     Assignee: (unassigned) => Timothy Symanczyk (timothy-symanczyk)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1529721

Title:
  Policy rules can be incorrectly applied with unscoped tokens

Status in OpenStack Identity (keystone):
  New

Bug description:
  Found this bug in kilo, but have confirmed that it can still be
  reproduced with a fresh install of master branch as of today.

  To reproduce the bad behaviour :

  1) Retrieve an unscoped token for any valid account.

  2) Using curl - invoke list_user_projects for the SAME user from step
  1 using the token from step 1, and observe that this works as
  expected.

  3) Alter the in-use policy file by inserting "role:service or " at the beginning of the rule for list_user_projects ...
  <     "identity:list_user_projects": "role:service or rule:admin_or_owner",
  ---
  >     "identity:list_user_projects": "rule:admin_or_owner",
  .... Note that the addition of this 'or' clause should not be able to logically cause any additional denials. 

  4) Try the identical curl command from step 2 again, and observe that
  it now fails with 403 Forbidden.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1529721/+subscriptions