yahoo-eng-team team mailing list archive

[Jeremy Stanley <fungi@xxxxxxxxxxx>]

Just to confirm, this is only a risk for the upcoming Pike release, not
a defect in current supported stable branches? If so, we would not issue
a security advisory unless it remains unfixed at release time per report
class Y ("Vulnerability only found in development release") in our
taxonomy: https://security.openstack.org/vmt-process.html#incident-
report-taxonomy

** Also affects: ossa
   Importance: Undecided
       Status: New

** Changed in: ossa
       Status: New => Incomplete

-- 
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/1703369

Title:
  get_identity_providers policy should be singular

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  identity:get_identity_providers should be
  identity:get_identity_provider (singular) since a GET is targeted on a
  single provider and the code is setup to check for
  identity:get_identity_provider (singular). See
  https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112

  found in master (pike)

  The ocata default policy.json also has this problem. Unless someone
  manually overrode policy to specify identity:get_identity_provider
  (singular), the result would be that the default rule was actually
  used for that check instead of identity:get_identity_providers. We
  could go back and fix the default policy.json for past releases, but
  the default actually has the same value as
  identity:get_identity_providers, and if nobody has complained it's
  probably safer to just leave it. It is, after all, just defaults there
  and anyone can override by specifying the correct value.

  But we must fix in pike to go along with the shift of policy into
  code. Policy defaults in code definitely need to match up with what
  the code actually checks. There should no longer be any reliance on
  the default rule.

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