Disabling projects can lock the user out of the system

[fuscata]

If you disable all the projects to which the currently logged in user has access, this user will be locked out of the system.

If you're the only admin, the only remedy is to edit the datbase by hand e.g.:

update keystone.tenant set extra = '{"enabled": true, "description": "-"}' where name = 'admin';

[Gabriel Hurley (gabriel-hurley)]

Totally true. I've actually walked someone through fixing this problem before, because they did exactly that. It's one of those "the user should know better, but we can stop them from shooting themselves in the foot" scenarios.

It's worth noting that there's still nothing preventing the user from doing this to themselves via the command line or API. Perhaps Keystone might want to look at this issue as well.

[fuscata (d-launchpad-fuscata-com)]

The problem in my case was that the user (me) assumed that an administrator would automatically have acess to all projects, including newly created ones.

[Gabriel Hurley (gabriel-hurley)]

I'd like to see this fixed in G1. We should simply have a check like we do for disabling your own user that prevents the action and warns the user if they try to remove their own admin rights. We could even recommend that they use the CLI if that's what they really wish to do.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/14286
Committed: http://github.com/openstack/horizon/commit/35a6708dccdc71d69a147daf0b0c2fde17489d4b
Submitter: Jenkins
Branch: master

commit 35a6708dccdc71d69a147daf0b0c2fde17489d4b
Author: Tihomir Trifonov <email address hidden>
Date: Wed Oct 10 17:29:20 2012 +0300

    User shouldn't remove their own roles on project

    Added a check if the user is trying to delete their
    own 'admin' role on the current project. This is added
    to prevent the users from locking their own
    access to Dashboard. Also, if the 'admin' role on the
    current project is removed, Dashboard automatically
    switches to another project for which the user has 'admin'
    role, but the previous project still is displayed as current.

    Fixes bug 1046538

    Also improved the unit test scenarios a bit.

    Change-Id: I1e60a11d628d6490ad24a8149b43ac307afb4780

[Dolph Mathews (dolph)]

Marking this as invalid because I think this is expected behavior for keystone. If a user does get themselves into this situation, the static admin_token defined by keystone.conf is intended exactly for this scenario- bootstrapping an admin user (or in this case, re-bootstrapping an admin user).