api.keystone.is_cloud_admin/is_domain_admin do not work with the latest policy from keystone repo

Bug #1739108 reported by Akihiro Motoki on 2017-12-19
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Critical
Radomir Dopieralski
django-openstack-auth
Undecided
Vladislav Kuzmin

Bug Description

openstack_dashboard.api.keystone.is_cloud_admin and is_domain_admin do not work with the policy files generated from the latest master branch (queens) of the keystone repository (For example, keystone commit cfbc2aa30b7406b4bc77e40a55561d1f46174b5c).

During the policy-in-code work, keystone drops "default" policy (which was "rule:admin_required").

is_cloud_admin() and is_domain_admin() refer to "cloud_admin" and "admin_and_matching_domain_id" policies respectively. They are not defined in the default keystone policy.
Previously a policy check fallbacks to "default" rule (i.e., "admin_required") and as a result both Is_cloud_admin() and is_domain_admin() checks "admin_required".

Now the keystone default policy has no "default" rule. As a result is_cloud_admin() and is_doman_admin() always returns False. This means some admin-ness panels do not work.

IIUC, the horizon policy framework intend to work with the default policies from back-end services.
The current situation should be fixed until Queens release.

[1] https://github.com/openstack/horizon/blob/0f598182919df31e40c7630ee1bd42bea259310d/openstack_dashboard/api/keystone.py#L325-L331

Akihiro Motoki (amotoki) on 2017-12-19
Changed in horizon:
importance: Undecided → Critical
milestone: none → queens-3
Akihiro Motoki (amotoki) wrote :

One idea is to make the policies used by is_cloud_admin() and is_domain_admin() configurable. We can use 'admin_required' as a default value. It behaves in a backward-compatible way.

I am not sure this is the right direction or not. If we need to do more than the above idea, folks familiar with keystone needs to be involved.

David Lyle (david-lyle) wrote :

The default behavior for policy in horizon is that if the rule is not defined, the policy engine in horizon returns True which means the action is allowed. I see nowhere that value is overridden. I'm not sure you have found the root of the problem.

Changed in horizon:
status: New → Incomplete
Akihiro Motoki (amotoki) wrote :

https://review.openstack.org/#/c/527668/ sync the policy file from the latest master of keystone repo.
After applying this, you cannot see "Modify Quitas" menu in the project panel.
"Modify Quotas" allowed() method refers to is_cloud_admin() [1], so at least I believe is_cloud_admin() does not work with the latest policy file.

While the root cause might be wrong, is it "Incomplete" bug report?

[1] http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/identity/projects/tables.py#n151

David Lyle (david-lyle) on 2017-12-20
Changed in horizon:
status: Incomplete → New
David Lyle (david-lyle) wrote :

The fix is to remove https://github.com/openstack/horizon/blob/master/openstack_auth/policy.py#L184-192. Those lines are wrong. The default for policy should be to allow, not block.

David Lyle (david-lyle) wrote :

The other option is to look for a "default" rule definition. If not present, allow. If present evaluate against it. This is closest to current behavior and leaves the option for operators to set a "default" rule in horizon's copy of the policy file.

Changed in horizon:
assignee: nobody → Radomir Dopieralski (deshipu)

Fix proposed to branch: master
Review: https://review.openstack.org/530488

Changed in horizon:
status: New → In Progress

Reviewed: https://review.openstack.org/530488
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=54365d7ef1007b3c8373ecb4e591c7f899dbeb98
Submitter: Zuul
Branch: master

commit 54365d7ef1007b3c8373ecb4e591c7f899dbeb98
Author: Radomir Dopieralski <email address hidden>
Date: Fri Dec 29 18:33:20 2017 +0100

    Fix api.keystone.is_cloud_admin/is_domain_admin handling with new policies

    Allow an action if no policy exists for it and there is no default
    policy.

    Change-Id: Ief6dc5ff15a83c70ee171774d1bfc6470c0863d1
    Closes-bug: 1739108

Changed in horizon:
status: In Progress → Fix Released

This issue was fixed in the openstack/horizon 13.0.0.0b3 development milestone.

Changed in django-openstack-auth:
assignee: nobody → Vladislav Kuzmin (vkuzmin-u)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers