Skip to content

users: Not clear about the difference between deleting local and remote users

To reproduce:

  • Have a user that accountsservice considers to be local, let's say localuser
  • Have another user that accountsservice considers to be remote (LDAP or similar), let's say remoteuser
  • Unlock the users panel
  • For each of those users:
    • Mouse over "Remove user" button
    • Click "Remove user" button

Expected result:

  • For localuser, what is going to happen is that the account will be deleted from /etc/passwd and /etc/shadow, and optionally the user's home directory will be deleted
  • For remoteuser, what is going to happen is that the account will disappear from the cached list of "interesting" remote accounts, but it will probably still be possible for remoteuser to log in to your computer (for example using the "Not listed?" button in gdm)
  • The buttons and tooltips should reflect that
  • The "are you sure?" prompt should also reflect that
  • Nice to have: some sort of indication (banner or icon or similar) that remoteuser is coming from a remote user directory and so the edits you will be able to do to it are likely to be limited

Actual result as of 43.0 (I haven't checked 44 prereleases):

  • There is no indication (banner or icon or similar) that remoteuser is coming from a remote user directory
  • In both cases the button is titled "Remove user"
  • In both cases the tooltip is "Delete the selected user account"
  • For localuser, the "are you sure?" prompt is as shown in #2093 (closed), which is not perfect, but it's reasonably clear about what is going to happen.
  • For remoteuser, the "are you sure?" prompt says: "Are you sure you want to revoke remotely managed remoteuser's account?". That uses the word "revoke" which makes me think "this is an authorization change, locking the user out", but that's not the case: the underlying accountsservice action is to "uncache" the user, which takes them off the shortlist on the gdm login screen but doesn't affect authorization.

The mockup on #2093 (closed) looks like an improvement for the localuser case, but I don't think it's a prerequisite for resolving this issue. My main concern here is the UX when the user is (or appears to be) remotely managed.

The reason I'm seeing this now is some orthogonal bugs in (Debian's patched version of) accountsservice: https://bugs.debian.org/1030253 which is Debian-specific, triggering https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107 which is not. These two bugs combine to get a local user account that accountsservice thinks is remote, and when that is combined with the gnome-control-center UI not being as clear as it could be, the result is that a user thinks they have deleted an account but then can still log in as that account (https://bugs.debian.org/1030262). Obviously that's mostly not gnome-control-center's fault, but if the remote-account UX was clearer, it would avoid misleading the user into thinking they had genuinely removed access.