Can we remove support for reading UID_MIN from /etc/login.defs in AccountsService?

AccountsService is a daemon that serves information about the human user accounts on the system. It is used on the login screen, the shell and control center for listing which users are available.

In Ubuntu we are carrying a patch that changes the logic for classifying which user accounts are human. The upstream behaviour is:

Check if the user account has a UID >= MINIMUM_UID and the user has a shell that is not nologin or false. MINIMUM_UID is configured at compile time (defaults to 1000).

In Ubuntu we change the behaviour to check if the account has a UID >= UID_MIN. UID_MIN is read from /etc/login.defs and defaults to 1000 if not set. This was the old behaviour of AccountsService.

Do we still need this patch? It seems to be there specifically for use in Ubuntu Touch, which doesn’t seem necessary anymore. Other distros don’t seem to be using this. There are accounts with UID greater than 1000 that show in Ubuntu which would be fixed by dropping the patch.

The obvious fix is to simplify the patch to only read UID_MIN from /etc/login.defs instead of using the compile time value (i.e. adding back the shell filter).

Is anyone actually setting UID_MIN to something other than 1000 and has users with UID < 1000 and a valid shell that should not be shown in the UI? It seems unlikely to me that would be the case. If not, then we can drop the whole patch.

This change was introduced in Debian in :

accountsservice (0.6.18-3) unstable; urgency=low

  * Revert upstream commit 552a0c856a6e3a7c2e6450ab80e79f4204062281
    and then fix a regression introduced since 0.6.16:
    - Filter out users which have UIDs lower than UID_MIN specified
      in etc/login.defs instead of checking if they have
      /usr/sbin/nologin as login shell. (Closes: #673095)
    Thanks to Michael Biebl for the report.

 -- Alessio Treglia <>  Wed, 16 May 2012 09:52:58 +0200

And later removed in:

accountsservice (0.6.37-1) unstable; urgency=low

  * New upstream release.
  * Refresh patches.
  * Drop 9001-memory_leaks.patch, no longer needed.
  * Disable 2001-filtering_out_users.patch, no longer applicable.
  * Update libaccountsservice0.symbols file.
  * Update debian/copyright.
  * Bump Standards.

 -- Alessio Treglia <>  Tue, 01 Apr 2014 14:41:18 +0100

Ubuntu added the change back in:

accountsservice (0.6.37-1ubuntu3) utopic; urgency=medium

  * debian/patches/0020-support-login.defs.patch:
    - Revert upstream patch that dropped support for using login.defs
      to determine min and max UID for system users.  We still want
      that support in at least Ubuntu Touch.

 -- Michael Terry <>  Wed, 21 May 2014 12:16:14 -0400


Actually it seems that this has accidentally been disabled in the development release (eoan) - when AccountsService switched to meson the default was changed from heuristics disabled to enabled. So I think we should continue with the behaviour like it is currently but please note here if this is an issue.

@robert.ancell: Have you noticed ?

I hadn’t noticed but the recent upload of accountsservice 0.6.55-0ubuntu7 will almost certainly fix this. It removes the patch and should hide users like this.

Possibly related:

The libvirt-qemu user showing up bug LP: #1674765 on debian/ubuntu systems would be addressed by honoring UID_MAX as well from login.defs. See the base-passwd git repo for details on static allocations happening in the uid 60000-64999 range.

The libvirt-quemu has their user shell set to /bin/false according to that bug report, so it shouldn’t show with the upstream AccountsService code.

I don’t think the crash is related to this, it looks like a bug in the ConsoleKit support.

And this didn’t work before under Unity (possibly bug in greeter or indicator-session). So with the patch removed the first user should always defaults to 1000.