Greeter does not show legacy users with uid < 1000

You are number 2 after asac apparently that has been done because of bug #427462, normal user uid are supposed to start to 1000 on debian and ubuntu

i carry my precious UID 501 around for 10 years or so ... would be great if we could fix a) gdm ... and b) debian policy to stop saying that users > 500 and < 1000 are system users.

i think the right fix for gdm would be to not check for UID, but rather whether an account is a "login" account ... i took a quick look and while there is a API way to parse passwd, getting the same for shadow was a bit less easy ... and gdm would need to run as root (from what i remember now).

still ... maybe something we could use consolekit for

i would say this is triaged.

possibly the best way to fix this regression is, as suggested by Milan in #247910, to utilize the UID_MIN setting in /etc/login.defs. another way would be to use the gdm MinimalUID setting which I believe is what was used prior to Karmic. However, seems it would make more sense for consistency to use /etc/login.defs since that is what for ex. is used in "users and groups". since this is a clear regression from jaunty i have to say that i'm a bit surprised by the priority being set to low.

My personal account at home is an old Mandrake one (some seven years old) with UID=501 and I have always kept it this way because thousands of files and dirs on my external disks has this owner and I am too lazy to chown all of them, but I'm used to manually change my user's id in /etc/passwd and /etc/login.defs before every new sys installation. If GDM used login.defs parameters, those small changes above will do all the job for me.
Thanks.

I changed my UID to 501, long while back, to match the one on my Mac, so that nfs works smoothly.

This was not a big issue before Karmic. After changing my UID, I would not see my username in 'Users and Groups', but I never used it regularly anyway. I wish I knew the /etc/login.defs trick before.

I noticed it in Karmic because the default GDM/Greeter had a face browser when I ran it from the LiveCD, but it was absent when I installed it on my computer. To me, it is an inconvenience. I would like to have the Face Browser.

I agree with jonas: there is already a configuration for this in /etc/login.defs. I'm testing a patch that reads this value.

My branch works as expected, and I see my user again, when it is not below UID_MIN

This bug was fixed in the package gdm - 2.29.1-0ubuntu9

---------------
gdm (2.29.1-0ubuntu9) lucid; urgency=low

  * debian/patches/24_system_uid.patch: use configured system UID
    minimum instead of hard-coded value (LP: #459199).
 -- Kees Cook <email address hidden> Wed, 16 Dec 2009 10:35:09 -0800

Any chance of getting that fix backported to Karmic?

I'd also like to see this regression fixed in Karmic.

why does the fix takes so much time?

the bug has been fixed in lucid, if you are speaking about karmic not sure it will be backported now since lucid will be available soon and user who have been using ubuntu with that issue for those months can probably wait an extra one now too

in lucid and with gdm version 2.29.92-0ubuntu8 legacy users are not shown and can't connect them.

This doesn't work anymore in natty (but it worked on maverick). I got a user with uid 504 that is display on GDM screen.

The fix to this bug is arguably incorrect. The UID_MIN value in login.defs is only for specifying the start of the range of dynamically-allocated UIDs assigned by useradd or newusers. It does not account for user accounts added to the system via other means, such as pre-existing accounts with long-established UIDs in large-scale environments.

For example, we have tens of thousands of users with UIDs that range from double-digits (that are approximately three decades old and still in use) up through the mid-14000s. We move the UID_MIN range up into the 58000s to prevent adduser (used only for creating machine-local user accounts that do not exist in the central account system) from creating accounts that conflict with UIDs of already existing accounts. This is the correct solution for moving the dynamicaly-allocated UID range out of the way of statically-allocated external UIDs.

However, the patch above causes gdm to only present login options for this dynamic UID range, and suppresses any account with a statically-assigned UID.

Now, the problem can be worked around because the patch uses the *first* value of UID_MIN that it finds in login.defs, while utilities that are actually supposed to read this file and use values from it use the last value they find. But adding wrong to wrong is just setting oneself up for future breakage.

tl;dr - This patch to gdm reads values from a file that doesn't belong to it, and uses them for purposes that they are not intended.

Proposed solution: Have gdm obtain its displayable account UID range from a location designed explicitly for such a purpose.

This is not working for me in Precise (12.04). Though UID_MIN is 500 in /etc/login.defs, gdm and lightdm do not show my UID 501 in the login screen.

I can confirm that it is not longer working in 12.04 LTS.

Pretty bad, because I migrated the first machine from openSUSE to Ubuntu and I have since a long time a established infrastructure with NFS3 and users in the range 500-1000.

Comment #19 rise up the general question what is the intention of in 12.04 LTS?
Should still UID_MIN influence gdm? Or is there a possibility to set the displayed UID range for gdm?

This is a problem for me using:
Distributor ID: Ubuntu
Description: Pop!_OS 19.04
Release: 19.04
Codename: disco

So I did a:
sudo nano -w /etc/login.defs

Changed to this:

UID_MIN 500
UID_MAX 599

Still not working so trying this as well:

sudo nano -w /etc/gdm3/custom.conf

Add this:

[greeter]
MinimalUID=500

Yet still not working. :(

This bug is 10 years old and closed already. If you experience any issues then please open a new bug by running:

  ubuntu-bug gdm3