gets confused about local/remote status of users that are considered non-human

https://bugs.debian.org/1030262

To reproduce:

• Be a user with administrative privileges
• Create a new (local, /etc/passwd + /etc/shadow) user account via gnome-control-center, but arrange through devious means for the user account to return false from user_classify_is_human()
  • In Debian this happened by mistake because we apply patches to use Debian adduser instead of useradd, and there was a behaviour change in adduser causing our accountsservice to be wrongly creating users with /usr/sbin/nologin. That's a Debian-specific bug and a fix is in progress, but it demonstrates that this is something that can happen by mistake.
  • Upstream, you can probably make this happen by creating a user account with one of the names in default_excludes[]. pvm is an example of one that is not reserved on my Debian system.
  • Upstream, I think you could also make this happen by having 50+ local user accounts already.
• Try to remove the newly-created user via gnome-control-center
• Inspect /etc/passwd and /etc/shadow
• Log out
• Try to log in as the newly-created-and-then-deleted user using gdm

Expected result:

• accountsservice thinks the user is a local user, because it ... is
• gnome-control-center implements its "Remove User" button as genuinely deleting the local user
• The user is removed from /etc/passwd and /etc/shadow
• You can't log in as it

Actual result:

• accountsservice thinks the user is a remote user (from LDAP or similar)
• gnome-control-center implements its "Remove User" button as merely removing the user from the cached list of "interesting" users, with an ambiguous message that doesn't make it particularly clear that the user account is not actually being deleted
• The user remains present in /etc/passwd and /etc/shadow
• gdm doesn't list the user in the shortlist of known users, because accountsservice doesn't list non-human local users unless they're cached
• You can still use "Not listed?" to log in by specifying the user's username
• Potentially a security problem if the reason you were deleting the account is because someone malicious knows its password

I'm reporting this as non-confidential (sorry!) because it's already non-confidential in the Debian bug tracking system.