OS-INHERIT does not seem to work for users but works for groups

Bug #1484577 reported by Christophe Balczunas
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Triaged
Medium
Henry Nash

Bug Description

Using Kilo, I'm following thehttp://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-inherit-ext.html#what-s-new-in-version-1-1 instructions to experiment with role inheritances on projects of a domain. (not dealing with subprojects just yet).

I'm having some problem getting OS-INHERIT to work when the target of the assignment is a user. It works if the target is a group.

I'm able to PUT a project role inheritance record but not get it back:

PUT: /v3/OS-INHERIT/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/daa86839ba154426ad34a95975d2d188/inherited_to_projects

(side note: I noticed though that it validates domain, roles, but not user. The PUT succeeds if I put an invalid user.)

HEAD on the same path above returns 404.

Also, this:
GET: /v3/OS-INHERIT/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/inherited_to_projects

returns 200, but an empty list of roles.

So somehow, the PUT doesn't stick, I'm not sure why. Consequently, I'm also not able to get a project token with expected roles from the domain etc.

Interestingly, this works with groups. In other words, if I do a:
PUT: /v3/OS-INHERIT/
domains/d
groups/g/
roles/x

then, a user from that group g can get a project scoped token with role x in any project of domain d.

It doesn't seem to be working when using the inherited grant on users directly?

summary: - OS-INHERIT does not seem to work for users but work for groups
+ OS-INHERIT does not seem to work for users but works for groups
Revision history for this message
Henry Nash (henry-nash) wrote :

Thanks for the detailed problem description. With regard to checking for existence of the user, this was by design (in preparation for potentially federated users coming in...although we may now be able to re-add that check since we handle federation a little differently than planned).

I'll investigate the other problem asap.

Dolph Mathews (dolph)
Changed in keystone:
importance: Undecided → Medium
status: New → Triaged
tags: added: kilo-backport-potential
Revision history for this message
Christophe Balczunas (pentatonic) wrote :

I was wondering when it gets decided if a bugfix gets backported to Kilo?

Also, have we identified that it is indeed a bug? Thank you.

Henry Nash (henry-nash)
Changed in keystone:
assignee: nobody → Henry Nash (henry-nash)
Revision history for this message
Henry Nash (henry-nash) wrote :

Hi

Sorry for the delay. Could you check to see if there is a non-inherited role off the same type, i.e. if

HEAD: /v3/OS-INHERIT/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/daa86839ba154426ad34a95975d2d188/inherited_to_projects

fails, then see if:

HEAD: /v3/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/daa86839ba154426ad34a95975d2d188

works?

There used to be a bug that we couldn't store both an inherited and non-inherited assignment on the same target...

works?

Revision history for this message
Christophe Balczunas (pentatonic) wrote :

Interesting. Yes if there is a domain role assignment for the user, then the inherited role doesn't work. If I remove the domain role first, then do the inherited role assignment only, it works.

Revision history for this message
Rudolf Vriend (rudolf-vriend-deactivatedaccount) wrote :

Just ran into the same issue.

I believe the problem has several causes:

- a unique composite primary key DB index on the assignment table that does not include the 'inherited' column and hence will prevent the definition of 'regular' and 'inherited' role assignments for the same set of assignment-type, actor_id, target_id and role_id (which should be supported IMHO).

- sql.DBDuplicateEntry exceptions are ignored during role assignment creation in create_grant and hence the api returns ok even if the call failed due to the unique index rejecting a 'duplicate' since it ignores the 'inherited' column.

Revision history for this message
Henry Nash (henry-nash) wrote :

OK, agreed, this is a known issue - and is fixed in Liberty (see: https://bugs.launchpad.net/keystone/+bug/1403539)

Revision history for this message
Henry Nash (henry-nash) wrote :

I'm closing this defect, since it is essentially a duplicate of https://bugs.launchpad.net/keystone/+bug/1403539. Please re-open if you think there is a distinct defect here.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.