Token without tenant - An unexpected error prevented the server from fulfilling your request. 'NoneType' object has no attribute 'get'

[Attila Fazekas]

If I issue the
# keystone --os_auth_url http://127.0.0.1:35357/v2.0/ --os_username demo --os_password pass user-list
a new token with null (None) tenant created in the database.

The console message without tenant parameter:

No handlers could be found for logger "keystoneclient.v2_0.client"
Invalid OpenStack Identity credentials.

Note:
   Console message with tenant paramter (No issue):
   You are not authorized to perform the requested action: admin_required (HTTP 403)

When I try to modify the demo user's role I get on error message I am using the admin users credentials correctly in environment variables:

# keystone user-role-add --user `keystone user-list| awk '/\| demo\s*\|$/{ print $2}'` --role `keystone role-list| awk '/\| admin *\|$/ { print $2}'` --tenant `keystone tenant-list| awk '/\| demo *\| True /{ print $2}'`

Or

keystone user-role-remove --user `keystone user-list| awk '/\| demo\s*\|$/{ print $2}'` --role `keystone role-list| awk '/\| admin *\|$/ { print $2}'` --tenant `keystone tenant-list| awk '/\| demo *\| True /{ print $2}'`

(I can't modify just the user who requested token without a tenant ID)

In the console I see:
An unexpected error prevented the server from fulfilling your request. 'NoneType' object has no attribute 'get' (HTTP 500)

Exception in the keystone log file:
Exception:
2012-10-13 01:14:34 ERROR [root] 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 184, in __call__
    result = method(context, **params)
  File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 528, in add_role_to_user
    self.token_api.revoke_tokens(context, user_id, tenant_id)
  File "/usr/lib/python2.7/site-packages/keystone/token/core.py", line 47, in revoke_tokens
    for token_id in self.list_tokens(context, user_id, tenant_id):
  File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 48, in _wrapper
    return f(*args, **kw)
  File "/usr/lib/python2.7/site-packages/keystone/token/backends/sql.py", line 99, in list_tokens
    if token_ref_dict['tenant'].get('id') != tenant_id:
AttributeError: 'NoneType' object has no attribute 'get'

Workaround:
Ignoring the tokens without tenant
                if token_ref_dict['tenant'] is None:
                    continue
I assume, it shouldn't be in the database so it is just a workaround.

Expected result:
 - Do not create invalid token entry
 - Always be able to change the users role as admin

Affected versions:
From Essex (openstack-keystone-2012.1.3-1.fc17.noarch) to latest git checkout on the weekend.

I can reproduce on a "clean" fedora 17 install. The installation based on the : http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17

I can send sql dumps wireshark captures or anything else.

[Joseph Heck (heckj)]

Attila,

I'm afraid this is a (crappy) side effect of the V2 API. When you get a token with just a username and password, the token returned is an 'unscoped' token and of very limited capability. Pretty much the only thing you *can* do with that token is to get a list of tenants (from the AUTH_URL, not the MGMT_URL) and request a token scoped to a tenant.

If you get a token starting off with requesting an appropriate project name - i.e. adding on --tenant-name=... to your arguments, you shouldn't have any issue from there.

[Attila Fazekas (afazekas)]

Joseph,

My problem is not the token I got is 'unscoped' and I can't list-users.

My problem is an unprivileged user, can prevent the administrator to change his roles.
The unprivileged user can do it even by accident.

In the above example the admin user requested a scoped token, just the demo user had unscoped token.

The the demo user's token stored in the database, which causes exception when I try to change the role of the demo user by a correct admin credentials.

[Hunter Nield (hnield)]

I can confirm that this is also happening for us today after patching Keystone to work around this issue - https://bugs.launchpad.net/keystone/+bug/1050025 (Ubuntu released their security fix for https://bugs.launchpad.net/keystone/+bug/1041396 but no follow up yet to fix 1050025).

1050025 and now 1068168 have seriously affected our custom Dashboard. We'll be investigating further but it something definitely occurring when managing roles.

[Joseph Heck (heckj)]

An unscoped token, which is what you requested, is *NOT* expected to be able to do administrative functions (which user-list is considered in the V2 API).

The error is terrible that it's given back (assuming a tenant when there isn't one for the unscoped token) - - rewriting some of the top of this bug to correct to returning a more useful error

[Attila Fazekas (afazekas)]

@heckj:
Is it fixed in keystone ?

I think it is not a client issue.

[Dolph Mathews (dolph)]

This is purely a client-side user experience issue as heckj described above.

Although keystone may provide a default tenant ID, keystoneclient should recognize unscoped credentials as a potential cause for failure when attempting operations that require any sort of authorization and simply amend the error message "Invalid OpenStack Identity credentials" with a suggestion that the user should try specifying a tenant via --os-tenant-name / OS_TENANT_NAME / --os-tenant-id / OS_TENANT_ID.

[OpenStack Infra (hudson-openstack)]

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

[Dolph Mathews (dolph)]

Unassigning due to inactivity.

[Steve Martinelli (stevemar)]

since we deprecated keystone CLI and this is working in openstackclient, for example:

$ env | grep OS
OS_PASSWORD=openstack
OS_AUTH_URL=http://172.16.240.138:5000/v3
OS_USERNAME=admin

$ openstack user list
Missing parameter(s):
Set a scope, such as a project or domain, set a project scope with --os-project-name, OS_PROJECT_NAME or auth.project_name, set a domain scope with --os-domain-name, OS_DOMAIN_NAME or auth.domain_name

we get the error message dolph described in comment #6