| 2015-12-29 23:11:02 |
Timothy Symanczyk |
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. |
How to reproduce this bug using keystone :
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. |
|
