Unable to reuse usernames

[Stuart Bishop]

'juju remove-user' does not actually remove the user, instead just disables it somehow. The user cannot be recreated, and instead a new username needs to be used.

This makes remove-user useless, as it should never be used because we are not prescient. If someone erroneously does run remove-user, the only way to recreate the user with the required username is to destroy and recreate the controller, or perform MongoDB surgery. Not being able to free the namespace is not an acceptable answer in most environments, as it will often be mandated by policy and other systems (eg. matching LDAP credentials so auditing tasks may be done).

[Sandor Zeestraten (szeestraten)]

Yes, this came up in bug 1668335, but it still an issue which prevents us from using users with Juju.

[Anastasia (anastasia-macmood)]

We do have some plans to renovate the way we've modeled user (for example, to use a primary key instead of username as an internal identifier).

However, it will not cover re-using usernames. Usernames must be unique for several reasons - non-repudiation and audit being some of them. Reinventing and inventing unique usernames are standard practice everywhere: if you have 2 employees that want the same username, they are generally forced to append a number or some similar tactic.

So given that:
1. we will not physically delete a user from our database (only logical deletes take place);
2. you as an operator want to re-use usernames from 'logically deleted' users;
3. we will be using user's primary key to link Juju components such as user permissions on models, etc...

then we can allow you to re-user a username as long as all other occurrences of this username are associated with 'logically deleted' users.

[Sandor Zeestraten (szeestraten)]

Apologies, but I'm a bit slow. Are you saying that you will at least support the use case of disabling (or logically removing) and re-enabling users?

[Anastasia (anastasia-macmood)]

@Sandor Zeestraten (szeestraten),

I am pretty sure that we currently support disabling (disable-user) and re-enabling (enable-user) users. I do not think that we support logically deleting user (remove-user) and then re-enabling it.

Note that commands in brackets already exist and are fully functional in Juju.

[Sandor Zeestraten (szeestraten)]

@Anastasia, I'm sorry but I still do not understand what the plan is.

Will administrators be able to delete users and re-enable or re-create them again or not?
If not, please as a minimum add some documentation and warnings so that people never use the remove-user command as it is a one-way door.

P.S. disable-user does not seem to work at all in it's current state. #1781442

[Tim Penhey (thumper)]

The plan is to rework how we identify users in the database. Right now we use the name as a primary key and using mongo's complete lack of referential integrity, if we enabled reusing usernames now we could remove one, add another and the ownership of things would effectively change.

We need to move to using an opaque primary key for users. The work is not currently scheduled, but we know we need to do it.

[Anastasia (anastasia-macmood)]

@Sandor Zeestraten (szeestraten),

To clarify:

Juju will NEVER physically delete a user.

Right now, an appropriate administrative operator can:

1. Logically delete a user. This user can never be active again.
2. Disable/enable a user. A disabled user will note lose their privileges on the system. This way, if the user is enabled again, they will still have the same access.

These operations exist now and will not be changed in anyway.

However, right now usernames are strictly unique - they cannot be re-used. My suggestion above will, in the future, allow username to be re-used as long as it's unique among all active, non-logically-deleted users.

Let me know if you are thinking of a scenario that is still unclear given the above information. Happy to talk you through a concrete puzzle.

[Loïc Gomez (kotodama)]

I fell into this trap today, and deleting the user was actually not what I should have done anyways.

This is the output of juju remove-user:
> WARNING! This command will permanently archive the user "xxxx" on the "yyy" controller.
>
> This action is irreversible. If you wish to temporarily disable the
> user please use the `juju disable-user` command. See
> `juju help disable-user` for more details.
>
> Continue (y/N)? y
> User "xxx" removed

Of course I should have noticed the wording, as "permanently archive" implies it won't be removed. But then, it says: User "xxx" removed.

This bug has been opened for more than 3 years, I guess a temporary solution would be to add more explicit warnings about what remove-user implies. For example, this would be more explicit:

> WARNING! This command will permanently archive the user "xxxx" on the "yyy" controller.
> This action is irreversible and you WON'T be able to reuse "xxx" username.
>
> If you wish to temporarily disable the user please use the `juju disable-user` command.
> See `juju help disable-user` for more details.
>
> Continue (y/N)? y
> User "xxx" archived, won't be able to login, and cannot be reused.

Thank you,
Loïc

[Heather Lanigan (hmlanigan)]

@kotodama, thank you for the wording suggestion. The PR below makes the change, and updates the error when attempting to add a removed user to make clear what is happening.

https://github.com/juju/juju/pull/13759

$ juju add-user charlie
ERROR failed to create user: cannot reuse name: user "charlie" is permanently deleted

[Loïc Gomez (kotodama)]

@hmlanigan, that's good news, thank you!

[Canonical Juju QA Bot (juju-qa-bot)]

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

[Paul Collins (pjdc)]

Possibly this bug can be closed due to the following being merged: https://github.com/juju/juju/pull/15266