useradd -r should start at the top of available uids

Axel Thimm Axel.Thimm at ATrpms.net
Fri May 5 17:53:56 UTC 2006


Currently the authoritative source of static uids/gids is

/usr/share/doc/setup-*/uidgid

The current LSB mandates that 0-99 are for static assignment and
100-499 are for dynamic assignment via useradd -r.

We are already at the border and there have been some assignments
beyond (that were just reverted) like 101 for gkrellmd. Security
considerations create a demand for more static uid/gids and there have
been some solutions suggested to effectively reserve some higher
ranges for semi-static reservations. This clearly shows the demand for
static uid/gid assignment. More on the security aspects can be found
in the wiki.

What I think will most probably happen is that LSB will revise the
need and find that the weighing of static vs dynamic sytem accounts
which currently is 1:4 needs to be rethought and maybe the bar lifted
from 100 to 150/200 or. What the LSB cannot do is touch anything
higher than 500 as that will break the users' playground (breaking
OSes is OK for the LSB ;)

To cut a long story short: We are currently allowed to use 100-499 for
dynamic assignment, but we will most probably have to violate the LSB
if a static uid/gid is needed as the range reserved for that is filled
up. So it makes sense to think about moving dynamic allocation of
uid/gid from the lower range to the upper range. E.g. the first
useradd -r grabs 499, the next 498 and so on. That way dynamic
allocation will not conflict with any (new) static assignments. That
scheme is therefore future proof (at least more than the current) and
will also survive any raising of the uid=100 border.

This has already been filed in bugzilla, so maybe you'd like to
comment there:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190523

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060505/b608680b/attachment.sig>


More information about the fedora-devel-list mailing list