DevHeads.net

UID_MIN & GID_MIN changed

Hi all,

I'd like to inform you that I have changed UID_MIN & GID_MIN from 500 to 1000
in upgraded shadow-utils.

Where?
/etc/login.defs.
shadow-utils-4.1.4.3-1.fc16

I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We are not
in situation that 500 IDs for system accounts ought to be enough for anybody.
Actually, it was not 500.It was 299 because range 0-200 is for reserved IDs.
There are 799 non reserved IDs for system accounts available after this
change.

Regards,
Peter.

Comments

Re: UID_MIN & GID_MIN changed

By Toshio Kuratomi at 05/24/2011 - 11:25

On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec < ... at redhat dot com> wrote:
* AFAIK, we actually have not run into the 500 uid limit yet (although
it is a bit low to be comfortable)
* AFAIK, we've only allocated the range 0-100 for reserved IDs.
* The 0-100 reserved IDs are actually the pain point that we need to
deal with, not the dynamic system ids in the 101-499 range.
* We don't know how many, if any IDs this actually gets us for the
dynamic range because any site that has already filled the 500-1000
UID range won't gain any extra dynamic system account through this
change.
* This could potentially break sites that are currently using the
500-1000 UID range and rely on the order of allocation of UIDs for
their users on new machines matching with the UIDs on old machines.
(For instance, NFS UIDs on filesystems matching between a box
installed with RHEL5 and a box that gets newly installed with F16).

-Toshio

Re: UID_MIN & GID_MIN changed

By Peter Vrabec at 05/25/2011 - 04:55

Hi,

On Tuesday, May 24, 2011 05:25:44 PM Toshio Kuratomi wrote:
I'm not against wider announcement. I'm just not sure what is the right way -
F16 Feature/Release Notes/ .... ? We can also annouce the 200 limit for
reserved IDs. ;)

Peter.

Re: UID_MIN & GID_MIN changed

By Toshio Kuratomi at 05/25/2011 - 14:07

On Wed, May 25, 2011 at 1:55 AM, Peter Vrabec < ... at redhat dot com> wrote:

Yes, we can release note it. But you still haven't answered the
question of why this change is necessary. Do you really have a system
where you have installed more than 400 packages that are allocating
dynamic system accounts?

We can't just make changes to this range. Especially not in the lower
end of it. (and if we change the dynamic system account range to
extend higher, we also can't use the 500-1000 range for that.

I notice that your patch on Monday to shadow-utils also canonicalized
this in the login.defs for the first time. Please revert that.

-Toshio

Re: UID_MIN & GID_MIN changed

By Peter Vrabec at 05/26/2011 - 03:27

Hi,

On Wednesday, May 25, 2011 08:07:32 PM Toshio Kuratomi wrote:
Changelog:
* Fri Mar 16 2007 Peter Vrabec < ... at redhat dot com> 2:4.0.18.1-11
- assign system dynamic UID/GID from the top of available UID/GID (#190523)

Some people were expecting this issue. :)

Re: UID_MIN & GID_MIN changed

By Toshio Kuratomi at 05/31/2011 - 14:47

On Thu, May 26, 2011 at 09:27:21AM +0200, Peter Vrabec wrote:

-Toshio

Re: UID_MIN & GID_MIN changed

By =?UTF-8?Q?Ond=C... at 06/01/2011 - 03:44

On Tue, 2011-05-31 at 11:47 -0700, Toshio Kuratomi wrote:
I guess Peter was talking about this 0-200 static ID reservation
threshold change - and it happened in Fedora 12 (setup-2.8.7-1.fc12)
with no reported complaints or conflicts so far.

Yes, static assignments are limited resource and it probably makes sense
to increase it even a bit further , however - in ~2 years since the
change of the threshold to 200, 15 static new uid's were assigned. So if
the trend will continue, there is enough free id's for reservation for
~5-10 years - so the threshold at 200 seems to be enough atm (especially
if the dynamically assigned system id's assignments are going from the
highest limit down).

Ondrej Vasik

Re: UID_MIN & GID_MIN changed

By =?UTF-8?Q?Ond=C... at 05/26/2011 - 04:41

On Thu, 2011-05-26 at 09:27 +0200, Peter Vrabec wrote:
Just a side note here... there are some third party
packages /applications which used/use static id's between 100 and
200 ... especially between 101 and 106 it is quite easy to find
"recommended" numbers for some apps. As Peter said, useradd assigns
dynamic system id's from the top of the range, going down - so the
conflicts with existing dynamic system accounts are really unlikely to
happen there.

Ondrej Vasik

Re: UID_MIN & GID_MIN changed

By Dennis Gilmore at 05/25/2011 - 13:37

On Wednesday, May 25, 2011 03:55:55 AM Peter Vrabec wrote:

another issue that i thought of was existing ldap/nis systems that allocate
regular users in the 500-1000 range when installing or upgrading if they use
policies that probit system accounts from logging in will have users unable to
login.

Dennis

Re: UID_MIN & GID_MIN changed

By Alexander =?ISO... at 05/26/2011 - 01:39

ons 2011-05-25 klockan 12:37 -0500 skrev Dennis Gilmore:

As someone who admins such an LDAP setup I think the sooner the change
is made the better. (If it had been changed long ago then it wouldn't
have been a problem now.)

Personally I think UIDs and their relation to user accounts should be
treated as host-local. I also want a pony.

/abo

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/26/2011 - 08:52

On Thu, 2011-05-26 at 07:39 +0200, Alexander Boström wrote:
It would be nice, but then there is NFS ...

Simo.

Re: UID_MIN & GID_MIN changed

By Casey Dahlin at 05/26/2011 - 16:29

On Thu, May 26, 2011 at 08:52:34AM -0400, Simo Sorce wrote:
NFSv4 has UID mapping, and we were all supposed to start using it
yesterday. My pony will have sparkles and rainbows.

--CJD

Re: UID_MIN & GID_MIN changed

By Alexander =?ISO... at 05/26/2011 - 16:12

tor 2011-05-26 klockan 08:52 -0400 skrev Simo Sorce:

Oh yes I'm well aware. (Not sure about CIFS and various other network
filesystems but at least AFS prefers a global UID space.)

There's also the problem with roaming UID-capable filesystems, like ext4
on a USB drive.

I really think all of those should have some sort of mapping between the
filesystem's and LDAP server's internal user id and the host-local UID
space.

But yes, ponies. My point is that until the above exists admins really
do need to be prepared to deal with UID collisions caused by changes in
the OS or by switching between OS:es or machines. Therefore it is ok for
the OS to extend the reserved range from 500 to 1000. (It's a 31-bit
range for crying out loud, there's plenty of room.)

/abo

Re: UID_MIN & GID_MIN changed

By Iain Arnell at 05/25/2011 - 12:26

On Wed, May 25, 2011 at 10:55 AM, Peter Vrabec < ... at redhat dot com> wrote:
How about slashdot's front page? Must be a really slow news day.

<a href="http://linux.slashdot.org/story/11/05/25/1312200/Fedora-16-Will-Number-UIDs-From-1000" title="http://linux.slashdot.org/story/11/05/25/1312200/Fedora-16-Will-Number-UIDs-From-1000">http://linux.slashdot.org/story/11/05/25/1312200/Fedora-16-Will-Number-U...</a>

Re: UID_MIN & GID_MIN changed

By =?UTF-8?Q?Ond=C... at 05/25/2011 - 05:06

On Wed, 2011-05-25 at 10:55 +0200, Peter Vrabec wrote:
Actually since July 2009 - there are no free uid/gid's left bellow 100.
And yes, I'm giving static assignments only for system accounts which
potentially can handle/own sensitive information or do communicate with
other systems - so I rejected some requests for static ID's reservation.

Probably makes sense :) ... even some ID sanity validator/checker might
be good idea for this "feature".

Ondrej Vasik

Re: UID_MIN & GID_MIN changed

By Dennis Gilmore at 05/24/2011 - 20:30

On Tuesday, May 24, 2011 10:25:44 AM Toshio Kuratomi wrote:
Im with Toshio here there is potential pitfalls with many legacy systems.
there is also great potential that system ids from newer systems will clash
with legacy ids in ldap and nis setups, we really should make it a feature as
it really deserves to be widely anounced. not quietly on the list here where
it will likely get forgoten until users are bitten when they start deploying
f16 boxes.

Dennis

Re: UID_MIN & GID_MIN changed

By =?UTF-8?B?IkrDs... at 05/25/2011 - 08:09

On 05/25/2011 12:30 AM, Dennis Gilmore wrote:
Agreed

Is there a distro wide/*nix wide agreement on what and which range
reserved/system IDs are supposed to be?

If there is not a general consciousness regarding reserved/system IDs
and what they are supposed to be there will always be the risk of
colliding with ids on other distribution and *nix platforms.

I recommend this be made a feature and the feature owners contact at
least all major distributions and potentially other *nix platforms and
distro/*nix wide consciousness be made and when this change is made that
change would reflect the consciousness that was reached.

JBG

Re: UID_MIN & GID_MIN changed

By Toshio Kuratomi at 05/25/2011 - 14:14

2011/5/25 "Jóhann B. Guðmundsson" < ... at gmail dot com>:
<a href="http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/uidrange.html" title="http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/uidrange.html">http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core...</a>

On problem is that the LSB is very strict in its ranges there but: 1)
not every distro follows it and 2) the static range is definitely too
small.

-Toshio

Re: UID_MIN & GID_MIN changed

By =?UTF-8?B?IkrDs... at 05/25/2011 - 16:04

On 05/25/2011 06:14 PM, Toshio Kuratomi wrote:
I would think first is to reach consciousness on what the
reserved/system IDs are supposed to be once that has been done we can
start looking at what is the best approach to implement and or fix
things that might break because of it.

We admins that are in mixed *nix environment and are stuck with legacy
uid/gid already have to *fix* the idiocy being done in configs and
application where the min UID/GID is set to anything but 100 (
restricted range ).

Basically we whom are living in and running legacy/mixed OS environments
are fucked already the main thing here is to reach consciousness across
distro's and preferably *nix platforms so we dont be in this crappy
situation again after 10 - 20 or 30 years time..

JBG

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/25/2011 - 16:14

On Wed, 2011-05-25 at 20:04 +0000, "Jóhann B. Guðmundsson" wrote:
Do you mean consesus ? We are pretty conscious of the uid/gid problem
space I believe :)

Changing the reserved id space should break "only" new allocations on
systems that may have used the newly allocated IDs already.
The only way to fix that is to have the admin manually intervene after
the error is brought to his attanetion.

Of course a softer way to deal with this is to not change the defaults
on upgrade if checks reveals IDs in the affected space. The problem is
that it may not be easy to determine this, esp when centralized ID are
also available via NIS/LDAP.

There is no need to insult developers that use defaults that are ok for
99% of the users and affect only legacy setups where poor decisions
where made wrt uid/gid allocations.

No default will ever please everyone.

You are asking the impossible, its unreasonable to set the bar to make
any change in this area to some sort of consensus that was not reached
in the past 30 years. It is effectively stalling the process and
preventing change. Which is unreasonable.

Simo.

Re: UID_MIN & GID_MIN changed

By Garrett Holmstrom at 05/26/2011 - 03:30

On Wed, May 25, 2011 at 1:14 PM, Simo Sorce < ... at redhat dot com> wrote:
This affects more than just the space between the old and new
SYS_UID_MIN. How will you ensure that accountsservice/gdm/etc
continue to enumerate preexisting user accounts with UIDs that are now
below UID_MIN? Can this be done while simultaneously preventing
system accounts in the new range from showing up?

Re: UID_MIN & GID_MIN changed

By Bruno Wolff III at 05/27/2011 - 09:25

On Thu, May 26, 2011 at 00:30:53 -0700,
Garrett Holmstrom < ... at fedoraproject dot org> wrote:
I can tell you they didn't. I can't login with gdm right now, most likely
because of this. gdm runs but doesn't list any accounts.
gdm should be looking at shells, not uids to decide which accounts to
present.

Re: UID_MIN & GID_MIN changed

By Bruno Wolff III at 05/27/2011 - 09:35

On Fri, May 27, 2011 at 08:25:21 -0500,
Bruno Wolff III < ... at wolff dot to> wrote:
Editing /etc/login.defs provides a work around for the gdm issue.
Though gdm has another oddity that it appears not to let me login
if I am logged into a vt.

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/27/2011 - 09:53

On Fri, 2011-05-27 at 08:35 -0500, Bruno Wolff III wrote:
Yeah I noticed as well that it tells you you are already logged in if
you login in a vt. That seem a much more serious bug.

Simo.

Re: UID_MIN & GID_MIN changed

By Adam Williamson at 05/27/2011 - 13:59

gdm tells you you're already logged in, but that doesn't stop you
logging in again. it's purely informational.

I'm not sure if it'd be considered a bug or not - I mean, you *are*
logged in, right? It'd depend what the intent of this notification is
exactly, I guess.

Re: UID_MIN & GID_MIN changed

By Bruno Wolff III at 05/27/2011 - 20:58

On Fri, May 27, 2011 at 10:59:20 -0700,
Adam Williamson < ... at redhat dot com> wrote:
In my case I wasn't able to login, but the system was in a screwy state
as I tried to get gdm restarted (so it would look at login.defs again)
and the previous instance wasn't completely dead. So it may not have been
being logged in on a vt that was really the problem.

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/27/2011 - 14:20

On Fri, 2011-05-27 at 10:59 -0700, Adam Williamson wrote:
I was confused by that, but now that I tried, I can actually log in.
Perhaps the icon should be turned into a terminal icon when you are
logged in through a vt (assuming gdm knows that detail).

Simo.

Re: UID_MIN & GID_MIN changed

By Evandro Fernand... at 05/27/2011 - 14:38

Em Sex, 2011-05-27 às 14:20 -0400, Simo Sorce escreveu:
It does, and it stops other users from shutting down the computer if
someone's logged in a VT. It's a great feature. :)

Cheers,
Evandro

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/27/2011 - 14:40

On Fri, 2011-05-27 at 15:38 -0300, Evandro Fernandes Giovanini wrote:
What I meant is: assuming gdm knows that that's a VT (ssh session ?) as
opposed to something else.

Simo.

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/27/2011 - 09:42

On Fri, 2011-05-27 at 08:25 -0500, Bruno Wolff III wrote:
If you click 'other' and type in your username it allows you to login
right ?
Does it "remember" your name once you logout ?

If not I call it a bug in gdm.

Simo.

Re: UID_MIN & GID_MIN changed

By Bruno Wolff III at 05/27/2011 - 10:41

On Fri, May 27, 2011 at 09:42:26 -0400,
Simo Sorce < ... at redhat dot com> wrote:
I wasn't given the other option. Possibly because I have no accounts without
UIDs over 1000.

To get signed in I modified /etc/login.defs. Hopefully it was only replaced
because I hadn't changed it, so it does rebreak with every shadow-utils
update.

I think the whole uid based test is broken anyway. A more reasonable algorithm
might be to ignore accounts with shells of /bin/false or /sbin/nologin and
include the rest. Or you could additionally skip accounts that have shells
that aren't in /etc/shells. (Taking into account an empty shell entry should
be treated as /bin/sh.)

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/26/2011 - 09:00

On Thu, 2011-05-26 at 00:30 -0700, Garrett Holmstrom wrote:
As far as I know GDM enumerates all users that logged in recently,
independently of where they come from and their UID number.

If this is not so a bug should be opened against GDM, as it has issue
with LDAP server that have users below 500 right now anyway.

And hopefully it does not actually list *all* users above 500, it would
be a nightmare on machines that have hundreds of users saved in local
files.

Simo.

Re: UID_MIN & GID_MIN changed

By Dennis Gilmore at 05/25/2011 - 20:04

On Wednesday, May 25, 2011 03:14:43 PM Simo Sorce wrote:
new installs in places with legacy systems cand and likely will be effected
with the result in cases being that users can not log into systems any longer.

Dennis

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/26/2011 - 08:56

On Wed, 2011-05-25 at 19:04 -0500, Dennis Gilmore wrote:
This is a worst case scenario and will not be that common. In those
cases admins will need to take corrective action, that may be annoying
in a very few cases, but not a tragedy. If you are using LDAP after all,
it is very unlikely you will go around creating new local user accounts
(and if you do you already have to make sure they do not conflict).

system users now have more space but they are not going to immediately
overflow about the uid 500 area, for most installations they will still
keeping being well below 500. And if your LDAP server has IDs below 500
you are already in a world of pain. If it has IDs between 500 and 1000
you are also in pain whenever you use debian based systems in your setup
too, and so you must already pay attention to what is going on in those
setups.

For these reasons I think excessive worries of doomsday scenarios are
unfounded.

Simo.

Re: UID_MIN & GID_MIN changed

By Jesse Keating at 05/26/2011 - 11:57

On 5/26/11 5:56 AM, Simo Sorce wrote:
Does this mean that non-static system UIDs will start being allocated
from the bottom of the pool again instead of the top? It seems that in
the past few years or so the UIDs and GIDs would be allocated from the
top, starting with 499 and working down. Is that changing? Forgive me
if this was covered earlier in the thread.

Re: UID_MIN & GID_MIN changed

By =?UTF-8?B?IkrDs... at 05/25/2011 - 18:34

On 05/25/2011 08:14 PM, Simo Sorce wrote:
Yup I meant conscious and I was refering to the uid/gid range

I'm pretty sure that things looked differently 20 - 30 years ago which
in my case is when those poor decisions as you call them were made.
( and encase anyone is wondering I was not the one that made those
decisions, I only get the *luxury* of dealing with them on daily bases )

True true

Has there been any effort in trying to address this problem in the past
thirty years?

What looks to me the mistake that lsb did in the first place was to
reserved an id range for dynamic allocation by system administrators and
post install scripts use.

I'm pretty sure if they had not done that and simply raised the bar on
reserved id to something high enough let's say 5000 or more and forced
everyone to apply for an id in the reserverd space we would not be
having this problem today...

JBG

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/24/2011 - 12:20

On Tue, 2011-05-24 at 08:25 -0700, Toshio Kuratomi wrote:
You need to force UIDs in that case anyway, and if you are not using
something like NIS or LDAP then you have to mange that manually anyways,
so I wouldn't make that a stopper for this very welcome change.

Simo.

Re: UID_MIN & GID_MIN changed

By John Reiser at 05/24/2011 - 13:45

On 05/24/2011 09:20 AM, Simo Sorce wrote:

No, you don't need to force them. ID 500 and up is the long-standing
default, so entering a small list of users [and particularly the _first_
user] in the same order will produce matching UID+GID on multiple machines,
even without NIS, LDAP, or "management".

Changing the floor to 1000 will create extra manual work for such users
who add a new system. Also, the change won't produce any net benefit
for users with NIS/LDAP/etc if they already have IDs in [500, 1000).
They will continue to use those IDs.

Re: UID_MIN & GID_MIN changed

By Simo Sorce at 05/24/2011 - 14:04

On Tue, 2011-05-24 at 10:45 -0700, John Reiser wrote:
Relying on a replay is quite fragile anyways, I don't think we really
need to cater for that case.
If you want to create the same user on multiple systems you really
either sync /etc/passwd file from a "master" machine or you adduser
specifying the uid and gid explicitly, anything else works by accident
already and is not something we really need to care about.

The change will not cause any issue to these users either so it's not a
big deal. After all in most cases anyone setting up an LDAP server has
chosen already saner defaults and decided to allocate user with IDs
higher then 1000 so to not conflict with local user on potential debian
based clients.

Simo.

Re: UID_MIN & GID_MIN changed

By Lennart Poettering at 05/24/2011 - 13:06

I agree that this chnage is very welcome, because it allows us to remove
one further difference between the various distributions.

Thank you,

Lennart