yahoo-eng-team team mailing list archive

[Dmitry Stepanenko <dstepanenko@xxxxxxxxxxxx>]

Public bug reported:

In commit eed233cac8f34ce74a2f6fa989c484773c491df3 "Concrete role assignments for federated users" there was added handling of federation-related objects. In that implementation objects like roles, projects and domains were aggregated from 2 sources - from appropriate tables directly and from federation-related hooks.
This mechanism can lead to situation when there's duplication of objects, so for such cases code for filtering out duplicates was added.

It was impemented in the following way:

domains = [dict(t) for t in set([tuple(d.items()) for d in domains])]

where domains is a list of dicts, each of which contains information
about appropriate domain. This code can work fine in some situations but
in general can work in a wrong way because dict "items" method returns
key-value pairs in arbitrary order according to
https://docs.python.org/2/library/stdtypes.html#dict.items. So, this
code may remain unchanged list of 2 similar dicts where items listed out
in a different order.

This code was introduced in upstream Thu Feb 25 21:39:15 2016, so it
seems that this code remains in newton and ocata and master branch.

** Affects: keystone
     Importance: Undecided
     Assignee: Dmitry Stepanenko (dstepanenko)
         Status: New


** Tags: federation

** Tags added: federation

** Changed in: keystone
     Assignee: (unassigned) => Dmitry Stepanenko (dstepanenko)

** Description changed:

  In commit eed233cac8f34ce74a2f6fa989c484773c491df3 "Concrete role assignments for federated users" there was added handling of federation-related objects. In that implementation objects like roles, projects and domains were aggregated from 2 sources - from appropriate tables directly and from federation-related hooks.
  This mechanism can lead to situation when there's duplication of objects, so for such cases code for filtering out duplicates was added.
  
  It was impemented in the following way:
  
  domains = [dict(t) for t in set([tuple(d.items()) for d in domains])]
  
  where domains is a list of dicts, each of which contains information
  about appropriate domain. This code can work fine in some situations but
  in general can work in a wrong way because dict "items" method returns
  key-value pairs in arbitrary order according to
  https://docs.python.org/2/library/stdtypes.html#dict.items. So, this
  code may remain unchanged list of 2 similar dicts where items listed out
  in a different order.
  
- This code was introduced in upstream Thu Feb 25 21:39:15 2016.
+ This code was introduced in upstream Thu Feb 25 21:39:15 2016, so it
+ seems that this code remains in newton and ocata and master branch.

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

Title:
  Removing duplicated items doesn't work in case of federations

Status in OpenStack Identity (keystone):
  New

Bug description:
  In commit eed233cac8f34ce74a2f6fa989c484773c491df3 "Concrete role assignments for federated users" there was added handling of federation-related objects. In that implementation objects like roles, projects and domains were aggregated from 2 sources - from appropriate tables directly and from federation-related hooks.
  This mechanism can lead to situation when there's duplication of objects, so for such cases code for filtering out duplicates was added.

  It was impemented in the following way:

  domains = [dict(t) for t in set([tuple(d.items()) for d in domains])]

  where domains is a list of dicts, each of which contains information
  about appropriate domain. This code can work fine in some situations
  but in general can work in a wrong way because dict "items" method
  returns key-value pairs in arbitrary order according to
  https://docs.python.org/2/library/stdtypes.html#dict.items. So, this
  code may remain unchanged list of 2 similar dicts where items listed
  out in a different order.

  This code was introduced in upstream Thu Feb 25 21:39:15 2016, so it
  seems that this code remains in newton and ocata and master branch.

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