yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #55517
[Bug 1616669] [NEW] Policy check target is inconsistent in use of domain_id
Public bug reported:
The code starting at
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/policy.py#L130
sets four keys on the policy check target equal to the user's domain id
(e.g the domain in which the user was created). Line 144 then reassigns
the 'domain_id' key with the domain to which the user has a scoped token
*if* they have such a token.
This creates a double meaning for domain_id. When keystone uses
'domain_id' in policy checks, the meaning is 'the domain to which a
token is scoped', so a check for 'is a domain admin' might be
'role:admin and domain_id:%(domain_id)s'. Under Horizon this doesn't
work, since the domain_id part essentially always passes, and thus a
project admin is indistinguishable from a domain admin.
My proposal is to set domain_id only if there is a domain scoped token.
If a policy check actually requires the user's domain, it can use
attributes on the token (token.user.domain.id).
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1616669
Title:
Policy check target is inconsistent in use of domain_id
Status in OpenStack Dashboard (Horizon):
New
Bug description:
The code starting at
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/policy.py#L130
sets four keys on the policy check target equal to the user's domain
id (e.g the domain in which the user was created). Line 144 then
reassigns the 'domain_id' key with the domain to which the user has a
scoped token *if* they have such a token.
This creates a double meaning for domain_id. When keystone uses
'domain_id' in policy checks, the meaning is 'the domain to which a
token is scoped', so a check for 'is a domain admin' might be
'role:admin and domain_id:%(domain_id)s'. Under Horizon this doesn't
work, since the domain_id part essentially always passes, and thus a
project admin is indistinguishable from a domain admin.
My proposal is to set domain_id only if there is a domain scoped
token. If a policy check actually requires the user's domain, it can
use attributes on the token (token.user.domain.id).
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616669/+subscriptions