clarify remove user message

[james beedy]

Having some trouble adding and deleting users. Users don't seem to *really* get deleted.....

bdx@xenial-dev:~$ juju --version
2.0-rc2-xenial-amd64

bdx@xenial-dev:~$ juju remove-user jcrosbie
WARNING! This command will remove the user "jcrosbie" from the "creativedrive-aws" controller.

Continue (y/N)? y
ERROR "jcrosbie" user not found
bdx@xenial-dev:~$ juju add-user jcrosbie
ERROR failed to create user: user already exists
bdx@xenial-dev:~$

[Richard Harding (rharding)]

For audit'ing purposes users don't get fully removed, they get turned
inactive. I'll have to look to see what we ended up with about exposing
that fact. Obviously the error message isn't helpful there.

On Wed, Oct 5, 2016 at 3:15 PM james beedy <email address hidden> wrote:

> Public bug reported:
>
> Having some trouble adding and deleting users. Users don't seem to
> *really* get deleted.....
>
> bdx@xenial-dev:~$ juju --version
> 2.0-rc2-xenial-amd64
>
>
> bdx@xenial-dev:~$ juju remove-user jcrosbie
> WARNING! This command will remove the user "jcrosbie" from the
> "creativedrive-aws" controller.
>
> Continue (y/N)? y
> ERROR "jcrosbie" user not found
> bdx@xenial-dev:~$ juju add-user jcrosbie
> ERROR failed to create user: user already exists
> bdx@xenial-dev:~$
>
> ** Affects: juju-core
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https://bugs.launchpad.net/bugs/1630728
>
> Title:
> user add/remove borked
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1630728/+subscriptions
>

[Paul Gear (paulgear)]

I'm seeing this message also: https://pastebin.canonical.com/169528/

It seems a lot more than a medium usability bug, though, because the user can't be added, removed, enabled, or disabled.

[Anastasia (anastasia-macmood)]

@Paul

As per our conversation on IRC, for non-repudiation purposes, Juju does not allow you to permanently/physically delete a user. For the same reason, an inactive user cannot be re-activated.

Enterprises and companies that have to abide by strict security policies, when faced with the need to give access to a person that had access revoked, for example, when hiring back a previous employee, create a new username. For example, "bob", "bob1", etc.

[Stuart Bishop (stub)]

How does this work with integrating with SSO systems where the username cannot be changed? We certainly need to reactivate users with the same username, and it isn't a particularly rare occurrence. This smells of username being used as a key in a system where it should not be (its common to need to rename users for instance, which is not the same as an add or delete operation)

I'm also not sure how this can function from an auditing POV. Where we grant users powers for limited periods of time (think supervised used by external contractors), we certainly want a single audit trail rather than separate audit trails for each active period. Less common is reenabling users after sabatical or rehires, but it still happens a few times a year.

[Sandor Zeestraten (szeestraten)]

Hitting the same issue here and it is really hindering us from sharing our controllers.
Creating a new username as an effort to "reactivate" the same folks is a no-no exactly for auditing purposes.

It is fair that you don't completely remove a user, however if that is the case then I absolutely expect that I am able to activate that user again.

[Cory Johns (johnsca)]

This bug is duplicating part of https://bugs.launchpad.net/juju/+bug/1629889

[Cory Johns (johnsca)]

I agree with Stuart that the auditing argument is a bit specious since auditing can and should be done by user ID instead of username.

[Jacek Nykis (jacekn)]

More use cases where users need to be enabled:
1. An individual changes team within the company and loose juju access. They change team again and need access back
2. Person leave the company, account is locked. They come back 6months later and need access

In both cases this can be worked around by creating new account like username2 but this causes audit problems in itself (2 accounts per individual, only one active)

[Tim Kuhlman (timkuhlman)]

I agree with Stuart that the right solution is to have a unique userid.

One other point that exacerbates the issue is that there is no way ahead of time to discover if a user is in this inactive state. My expectation was that sincethe '--all' flag exists it should show the inactive users:

$ juju users --all
Controller: local

Name Display name Access Date created Last connection
admin* admin superuser 2017-01-19 just now

$ juju add-user test-user
ERROR failed to create user: user already exists

[Anastasia (anastasia-macmood)]

Adjusting Importance as it affect many users. Also renaming to reflect desired change in functionality rather than a change in error message.

[Paul Gear (paulgear)]

As well as needing the ability to reactivate users, we'll need to be able to create a new registration string for them.

[Reed O'Brien (reedobrien)]

I'll write up something more detailed to try steering toward a proper solution. But in the meantime...

If you want to temporarily activate/enable and deactivate/disable users -- as in the earlier example of a contractor -- use the juju dis/enable-user commands.

$ juju disable-user jjam
User "jjam" disabled
$ juju enable-user jjam
User "jjam" disabled

As noted previously in this thread remove-user archives a user permanently, never to be revived. The short answer to why is auditing. The longer answer is that the user name is the user id. That user id/name is used in the key for other items. We don't destroy or change owner when we remove a user so we don't want to create a new user that would then have access to things the previous user of the same name had access too.

I agree that users and authn/z should be overhauled, but that is a larger coversation. In the mean time I'll take a stab at making the confirmation text much more explicit (e.g. disable vs. remove) and the error more appropriate (e.g. username not available). Similarly in Paul's case the errors should note the user is gone/unavailable not "user already exists".

On develop, I don't see an error after confirming I want to remove a user. That does look like a bug if it is happening.

[Reed O'Brien (reedobrien)]

I'll also put together an email with some thoughts for evolving users and authnz.

[Anastasia (anastasia-macmood)]

Note that develop mentioned in comment # 12 is current tip for 2.2 work.

[Anastasia (anastasia-macmood)]

User management that included enable/disable/remove users has been available in Juju since 2.x.

Here is more command related information:
https://jujucharms.com/docs/2.0/users-manage
https://jujucharms.com/docs/2.0/users

[james beedy (jamesbeedy)]

Playing around with 2.0.3 (using the hosted controller), it seems I cannot
perform any model lifecycle operations as 'admin' on another user's model.

Consider the following use case/sequence of events:

1. Juju user Fred creates model 'foo-model'.
2. As the owner of the 'foo-model', Fred grants 'admin' on 'foo-model' to
Bob.
3. Fred leaves the team/company/project/site.

Bob doesn't have the ACL to perform model lifecycle ops on 'foo-model', how
is the lifecycle of 'foo-model' maintained following the event where the
owner does not need to be enabled on the model any longer? Moreover, how
can an owner be disabled on his/her own model?

[Reed O'Brien (reedobrien)]

PR up at https://github.com/juju/juju/pull/7035

[John A Meinel (jameinel)]

I believe comment #16 might be a tangent for this particular bug, but "Owner" should just be yet-another admin, and not particularly special, other than when you create a model, you're automatically in the admin set.

We should not have a separate "owner" tag that has special permissions.