← Back to team overview

yahoo-eng-team team mailing list archive

[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