Users with UID > 60000 are invisible in login and Settings->User unless /etc/login.defs updated

After update to 14.04 The user even vanishes from login screen

I am using fresh install of Xubuntu 14.04 and I have a slightliy different behaviour than what is described above:

1. create a user with uid = 60001 (e.g change uid for an existing user in extended settings from users-admin dialog)
-> Result: The user is neither shown in the users-admin dialog, nor in lightdm-greeter, but can of course still log in manually.

2. in /etc/login.defs set UID_MAX=99999999
-> Result: the user *is* shown in users-admin dialog and after *reboot* the user also *reappears* in the lightdm-greeter
- Note: a simple 'service lightdm restart' was not enough, I had to do a full reboot!

So for me changing the UID_MAX in login.defs is a usable workaround, but it definitely should be documented, at least in the users-admin gui. Also a short note about the dropped users and a hint to the woraround (solution?) should be shown in the lightdm-logs.

Warning: I don't know yet, whether this setting in login.defs has some other security implications. I just noticed that there is a couple of new setting files concerning id ranges for "subordinate user ids" (e.g. /etc/subuid), which use some "uids" in distances of 65535. Sadly even after searching for quite a while I still don't have a clue what they are for.

The component that is reading UID_MAX is accounts service which is why restarting lightdm would have no effect.

The reason they show on the 13.10 login screen is bug 1248541 had not been fixed - LightDM was showing users that accountsservice considered "system" (i.e. with a UI >= UID_MAX).

There seems to be no good reason to consider users with UID > UID_MAX so the best solution is probably to remove that check.

That last comment should be "There seems to be no good reason to consider users with UID > UID_MAX are system accounts so the best solution is probably to remove that check."

This bug was fixed in the package accountsservice - 0.6.37-1ubuntu4

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

  * debian/patches/0020-support-login.defs.patch:
    - Don't use UID_MAX - all system users will be below UID_MIN and using
      UID_MAX hides valid users on systems with large UIDs (LP: #1290785)
 -- Robert Ancell <email address hidden> Tue, 24 Jun 2014 11:34:15 +1200

Questions:
As I reported this bug for updated systems: have ou tried this as well?
I do not have the chance to have simply a fresh install: did you also test with big UIDs as reported? 8 digit numbers?

Where can I get the fix to test it? It is not yet visible in trusty-proposed?

I only see 0.6.35-0ubuntu7

This is not fixed :(

I installed manually on my 14.04 instance:

https://launchpad.net/ubuntu/utopic/amd64/accountsservice/0.6.37-1ubuntu4
https://launchpad.net/ubuntu/utopic/amd64/init-system-helpers/1.18
https://launchpad.net/ubuntu/utopic/amd64/libaccountsservice0/0.6.37-1ubuntu4

rebooted fully and no change.

I was not yet able to test the fix mentioned above. But I noticed that with my workaround the user "nobody" (uid 65534) is listed as in lightdm.
It is listed by accountsservice if I query it via dbus:

root@pc:~/tmp# qdbus --system org.freedesktop.Accounts
/
/org
/org/freedesktop
/org/freedesktop/Accounts
/org/freedesktop/Accounts/User65534
[..]
/org/freedesktop/Accounts/User1000

Hopefully this has been taken care of in the patched version?

I'll try to test the utopic version tomorrow.

@Robert Ancell:
1. is this the correct way to restart the accountsservice?:
/usr/lib/accountsservice/accounts-daemon --replace &

2. I couldn't find a lot of documentation for accountsservice could you give me a hint for a good start?

I can confirm that I do see the nobody user in the accounts screen. I do not see my user with UID 10203040.

I fixed the nobody issue in 0.6.37-1ubuntu5

@Robert - the easiest way I found to restart accounts service is:
$ sudo killall accounts-daemon
- it will be respawned when it is contacted again (e.g. when a greeter starts)

There's not a lot of documentation on accounts service - http://www.freedesktop.org/wiki/Software/AccountsService/ is your best info.

I have just tried the 0.6.37-1ubuntu5 versions for Utopic and they kinda work as expected.:
- I can see users with UID> 60000
- 'nobody' is not listed anymore

BUT: after some fiddling, one user (with uid 101125) is not shown any longer in the Lightdm login window (even after reboot), but when I query the accounts-daemon via dbus the user does show up:

# qdbus --system org.freedesktop.Accounts
/
/org
/org/freedesktop
/org/freedesktop/Accounts
/org/freedesktop/Accounts/User101265
/org/freedesktop/Accounts/User101139
/org/freedesktop/Accounts/User101125
/org/freedesktop/Accounts/User1000

I have previously had the same problem with the normal trusty-Packages and the raised UID_MAX limit. But back then I didn't investigate, but just reinstalled.

Is there any other place where usernames are removed from the list shown in lightdm?
Could this be the same problem why Jan does not see his user?
For now I will not touch this system so I can do some further testing.

Some Background info: all users above 100000 are domain users mapped by winbind. The only difference I can see between the user not showing up and the others is that the former was added to some local groups. But removing him from theese groups did not help, so I think it's not related.

@Robert - thanks for the hints, too bad that such a central component is documented so poorly :-(
I just had to figure out that the accounts-daemon seems to take some time to start up: after the killall only the second qdbus query gives results

- I tried to backport your changes from /debian/patches/0020-support-login.defs.patch in accountsservice_0.6.37-1ubuntu5 to the /debian/patches/2001-filtering_out_users.patch in trustys accountsservice_0.6.35-0ubuntu7 only to find out that this is not used at all. I found the /debian/patches/ directory quite crowded (messy?). Maybe I'll try again tomorrow.
Could you please provide a backport of these patches for trusty? Thanks a lot.

If you have an account which is not showing in the greeter using Ubuntu 14.10 with the updated packages please provide the following information on the user:
$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User1000 --method org.freedesktop.DBus.Properties.GetAll org.freedesktop.Accounts.User

(replace 1000 with the UID)

LightDM shouldn't hide any users so hopefully one of the user properties should indicate why it isn't being shown.

This seems to lead into the right direction - my user account ist classified as 'SystemAccount':

root@pc220hh2:~# for i in 1000 101265 101125 101139; do gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$i --method org.freedesktop.DBus.Properties.GetAll org.freedesktop.Accounts.User|sed -e 's/),/),\n/g;s/>,/>,\n/g'|grep SystemAccount; done
 'SystemAccount': <false>,
 'SystemAccount': <false>,
 'SystemAccount': <true>,
 'SystemAccount': <false>,

But why?
I will attach the full info for this user.

Thanks to the hint from Robert, I finally found a solution for my user to be listed again:

There actually seems to be a method for setting the account type in the interface of org.freedesktop.Accounts.User, namely 'SetAccountType(in i accountType);' but I could not find a list of valid values for accountType. So I just uncached and then (re-)cached the user:

gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts --method org.freedesktop.Accounts.UncacheUser euhus
()
gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts --method org.freedesktop.Accounts.CacheUser euhus
(objectpath '/org/freedesktop/Accounts/User101125',)

Now the 'SystemAccount' property is set to false and the user is shown in the login window.

But I still have no idea, why this account was ever marked as system account.

What stil remains to be done is release a fix for the currently stable (and even LTS-) release.

P.S.: to find out about the available methods etc. I used:
gdbus introspect --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts --recurse | less

Poking around a bit further it seems like the 'SetAccountType(in i accountType);' method mentioned above can take only values of 0 and 1 (which I would rather regard as boolean, than integer) and changes only the 'AccountType' property of that user. This property seems different from the SystemAccount property.

I have no idea what the AccountType means, but i noticed that it is set to 1 for my local user and to 0 for the domain/winbind users. On the other hand, there is another special boolean property called LocalAccount ....... oh well, who needs docs anyway?

So to me it looks like there is no way to correct the wrongly detected SystemAccount property for a user, but to Uncache and then Cache this user.

I have attached the backported patch of the changes from the above mentioned 0.6.37-1ubuntu4 and 0.6.37-1ubuntu5 to trusty's 0.6.35-0ubuntu5 accountsservice.

This needs to be put into the debian/patches/ directory and added to debian/patches/series and debian/patches/ubuntu.series

I have successfully built and tested packages with this using pbuilder.

btw: I think the 2003-dont-use-max_uid-from-login.defs.patch should be removed from the debian/patches/ directory in trusty, since it is not used there.

@Robert: would You please build and upload an official package for trusty?

Robert, the user cache is /var/lib/AccountsService/users/. It would seem that there may be an issue here for accounts that are created before the patches may be marked as system accounts until the cache is refreshed.

The trusty version is uploaded to the archive and is awaiting an archive administrator to push it through. Then it will need to go through the SRU process:
https://wiki.ubuntu.com/StableReleaseUpdates

Robert, if I found the correct sources, then I Ithink something went very wrong with your patch for trusty:

I found sources for version 0.6.35-0ubuntu7.1 here: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 , namely:
http://launchpadlibrarian.net/179519600/accountsservice_0.6.35-0ubuntu7.1.dsc
http://launchpadlibrarian.net/179519599/accountsservice_0.6.35-0ubuntu7.1.debian.tar.xz
http://launchpadlibrarian.net/179519598/accountsservice_0.6.35.orig.tar.gz

and the diff:
http://launchpadlibrarian.net/179519604/accountsservice_0.6.35-0ubuntu7_0.6.35-0ubuntu7.1.diff.gz

As one can already guess from the diff, this is not only the patch mentioned above, but quite a lot of aclocal/m4 files were simply removed from the sources.

This leads to build errors as you can see from the attached log excerpt from a pbuilder run.

The old version accountsservice_0.6.35-0ubuntu7 compiles without any problems, but the new one just doesn't. compile at all.

Please correct this.

After some more search I found that the "original" gzipped tar archive that is referenced in your new version accountsservice_0.6.35-0ubuntu7.1.dsc differs a lot from the xz-compressed "original" tar used by the old trusty version:
https://launchpad.net/ubuntu/+archive/primary/+files/accountsservice_0.6.35.orig.tar.xz

This is exactly the difference seen in the diff mentioned above.

In the attached accountsservice_0.6.35-0ubuntu7.1.dsc I have just replaced all references to the dubios accountsservice_0.6.35.orig.tar.gz by the corresponding lines for accountsservice_0.6.35.orig.tar.xz as found in https://launchpadlibrarian.net/162749972/accountsservice_0.6.35-0ubuntu7.dsc
(and removed the pgp signature).

With this change the packag compiles cleanly and works as expected.

@Robert: please use the working original tar.xz from the old package and repost the patch. Thanks.

I think Robert E. is right; there was something weird with the original tar.xz file. I asked Sebastian Bacher to remove the package from the upload queue, and then I re-uploaded.

Robert A.: Hope you don't mind. ;)

Thanks Gunnar! I misread your comment and uploaded as well. Both uploads seem identical though :)

Hello Jan, or anyone else affected,

Accepted accountsservice into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/accountsservice/0.6.35-0ubuntu7.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hi Chris and everyone involved,

I can confirm, that this new package from trusty-proposed fixes the problem. Users with a higher UID (e.g. 101125 here) are shown and 'nobody' is hidden.

I have just tested this on a fresh install of trusty Xubuntu with the proposed repository enabled as described in https://wiki.ubuntu.com/Testing/EnableProposed

Just for completeness, here is a list of the installed package versions from apt-cache policy:

accountsservice:
  Installiert: 0.6.35-0ubuntu7.1
  Installationskandidat: 0.6.35-0ubuntu7.1
  Versionstabelle:
 *** 0.6.35-0ubuntu7.1 0
        400 ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/ubuntu/ trusty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.6.35-0ubuntu7 0
        500 ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/ubuntu/ trusty/main amd64 Packages
libaccountsservice0:
  Installiert: 0.6.35-0ubuntu7.1
  Installationskandidat: 0.6.35-0ubuntu7.1
  Versionstabelle:
 *** 0.6.35-0ubuntu7.1 0
        400 ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/ubuntu/ trusty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.6.35-0ubuntu7 0
        500 ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/ubuntu/ trusty/main amd64 Packages

Thanks a lot to everyone involved! I just hope this arrives in trusty-updates soon :-)

Yours,
Robert

As an affected user, I can also verify that this fixes the issue.

This bug was fixed in the package accountsservice - 0.6.35-0ubuntu7.1

---------------
accountsservice (0.6.35-0ubuntu7.1) trusty-proposed; urgency=medium

  * debian/patches/0018-no-max-uid.patch:
    - Don't have a maximum UID (LP: #1290785)
 -- Robert Ancell <email address hidden> Fri, 18 Jul 2014 12:26:01 +1200

The verification of the Stable Release Update for accountsservice has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Back from parental leave I could finally update my system. Important is to uncache the user on an already affected system as described by Robert Euhus in comment #18

    gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts --method org.freedesktop.Accounts.UncacheUser euhus

Thanks for fixing :) My first contribution to ubuntu (proud) :D