Keystone adds role to non-existing user in specific tenant by API

[Sagi (Sergey) Shnaidman]

Icehouse, discovered during tempest testing:

Scenario is adding role to non-existing user in specific tenant:

Tenant-id = 2775ce375d624735b49347cdac41a946
Role-id = 9fe2ff9ee4384b1894a90878d3e92bab
User-id is some junk, like: junk-user-id-2999

The problem exists only in API requests, cli command reports an error:

@all-in-one:~# keystone user-role-add --user user-junk-id-101010 --role 9fe2ff9ee4384b1894a90878d3e92bab --tenant 2775ce375d624735b49347cdac41a946
No user with a name or ID of 'user-junk-id-101010' exists.

With API:

1) Authenticate and get token:
curl -d '{"auth":{"tenantName": "openstack", "passwordCredentials": {"username": "admin", "password": "admin_password"}}}' -H "Content-type: application/json" http://localhost:35357/v2.0/tokens > /tmp/aaa
sed -i 's/.*"id": "\(.\+\)==.*/\1==/g' /tmp/aaa

2) Add existing role in existing tenant to non-existing user "junk-user-id-2999":
curl -i -H "X-Auth-Token:`cat /tmp/aaa`" -X PUT http://localhost:35357/v2.0//tenants/2775ce375d624735b49347cdac41a946/users/junk-user-id-2999/roles/OS-KSADM/9fe2ff9ee4384b1894a90878d3e92bab

output means success:
{"role": {"enabled": "True", "description": "Default role for project membership", "name": "_member_", "id": "9fe2ff9ee4384b1894a90878d3e92bab"}}

3) repeat the last request and get output:
{"error": {"message": "Conflict occurred attempting to store role grant. User junk-user-id-2999 already has role 9fe2ff9ee4384b1894a90878d3e92bab in tenant 2775ce375d624735b49347cdac41a946", "code": 409, "title": "Conflict"}}

Seems like user is self-added.
Although there are no such users in this tenant:
curl -H "X-Auth-Token:`cat /tmp/aaa`" http://localhost:35357/v2.0/tenants/2775ce375d624735b49347cdac41a946/users
--- no junk-user-id-2999 here ---

Seems like there is no user id check in API.

[Dolph Mathews (dolph)]

keystone user-role-add might be determining that "user-junk-id-101010" is not a valid user ID, and thus making a different API call? Either way, keystone should consistently throw an error given invalid input.

[Juan Manuel Ollé (juan-m-olle)]

After investigate this issue and find a possible fix, I found out this test, it creates some opens to me

def test_get_project_users_no_user(self):
        """get_project_users when user doesn't exist.

        When a user that's not known to `identity` has a role on a project,
        then `get_project_users` just skips that user.

        """

It seems that an unexistent user could have a role. Perhaps after deleting the user?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/93982

[OpenStack Infra (hudson-openstack)]

Change abandoned by Juan Manuel Ollé (<email address hidden>) on branch: master
Review: https://review.openstack.org/93982

[Adam Young (ayoung)]

I'd like to defer this fix until the next release. There are at least two cases where a userid is not known up front (Federation, Multi-LDAP) that could potentially be supported by this approach. We should not be looking for users in the backend before assignment.

[Lance Bragstad (lbragstad)]

This was discussed in the Keystone weekly meeting and we've decided to hold the fix for this until Kilo opens for development.

[Lin Hua Cheng (lin-hua-cheng)]

After spending more time with the code, the validation that user/group should exists when assigning roles in V3 was really not removed!

Here is what I found:

1. There are still rest running that when non-existing user is assigned, it should return 404:

https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_v3_assignment.py#L994
https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_v3_assignment.py#L1072

2. Grant crud operation is using a protection callback that validates that the user/group should exist. So an non-existing user/group could never be created.

https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L346-L367

We just need to add back the user validation for role assignment for V2.

[Steve Martinelli (stevemar)]

refer to patch https://review.openstack.org/#/c/93982/

[David Stanek (dstanek)]

Is this behavior we really want to change if it's only for v2? We have already declared v2 as old and busted. Additionally this could break systems that rely on this behavior. I don't care either way, but would like others to weigh in here.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Morgan Fainberg (<email address hidden>) on branch: master
Review: https://review.openstack.org/93982
Reason: Administratively abandoning. This is V2 only and a behavior some deployers use. We dont need to fix this and with v2 being deprecated, the bug will be marked as "wont fix"

[Morgan Fainberg (mdrnstm)]

V2 is deprecated and this behavior has been supported (intentional or not). We can't really fix it, it will go away with the V2 api being dropped.