yahoo-eng-team team mailing list archive

[Marcos Lobo <1284639@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

The list_projects_for_user() function on LDAP assignment backend only
search projects with associations across user_id, not across group_ids.
This function admits the group_ids parameter, but never is used on the
body of the function.

I think is necessary change this function to can search projects with
associations across user_id and group_id.

USE CASE:
---------------
Check if user named 'u1' (inside group 'G2') has grants on project named 'p1'. We have this hierarchy:

P1 <- G1 <- G2 <- U1

In this use case, user 'U1' should have grants on project 'P1' because
user 'U1' belongs to group 'G2', 'G2' belongs to 'G1', and 'G1' has
grants on 'P1'.

What happens to the current code:
----------------------------------------------------
User 'U1' has not grants on project 'P1'. That is because list_projects_for_user() only search associations between user and project directly and not between groups and projects.

** Affects: keystone
     Importance: Undecided
     Assignee: Marcos Lobo (marcos-fermin-lobo)
         Status: New

** Changed in: keystone
     Assignee: (unassigned) => Marcos Lobo (marcos-fermin-lobo)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1284639

Title:
  Unimplemented get roles by group for project list

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The list_projects_for_user() function on LDAP assignment backend only
  search projects with associations across user_id, not across
  group_ids. This function admits the group_ids parameter, but never is
  used on the body of the function.

  I think is necessary change this function to can search projects with
  associations across user_id and group_id.

  USE CASE:
  ---------------
  Check if user named 'u1' (inside group 'G2') has grants on project named 'p1'. We have this hierarchy:

  P1 <- G1 <- G2 <- U1

  In this use case, user 'U1' should have grants on project 'P1' because
  user 'U1' belongs to group 'G2', 'G2' belongs to 'G1', and 'G1' has
  grants on 'P1'.

  What happens to the current code:
  ----------------------------------------------------
  User 'U1' has not grants on project 'P1'. That is because list_projects_for_user() only search associations between user and project directly and not between groups and projects.

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