Bug 190523 - useradd/groupadd -r should start at the top of available uids/gids
useradd/groupadd -r should start at the top of available uids/gids
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
David Lawrence
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-03 05:22 EDT by Axel Thimm
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-26 10:45:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch, any review is appreciated (2.59 KB, patch)
2007-03-09 09:37 EST, Peter Vrabec
no flags Details | Diff
better candidate (4.00 KB, patch)
2007-03-12 07:26 EDT, Peter Vrabec
no flags Details | Diff

  None (edit)
Description Axel Thimm 2006-05-03 05:22:39 EDT
Description of problem:
Using useradd -r w/o assigning an explicit uid will assign uid that have been
reserved in /usr/share/doc/setup-*/uidgids. When installing the package that has
this uid assigned the package will fail.

Version-Release number of selected component (if applicable):
shadow-utils-4.0.14-6.FC5

How reproducible:
always

Steps to Reproduce:
1.Use useradd -r
2.Install gkrellm-daemon or similar
3.
  
Actual results:
gkrellmd user is not created, because uid 101 is occupied

Expected results:
Either all uid/gids in the setup package should be in the initial passwd/group
file (then this bug needs to move to the setup package), or useradd/groupadd
need to be more conservative with dynamic registration e.g. start at the top of
the available system slots. I'd prefer the latter as new official static
registrations will still be possible in updates/upgrades of the system.

Additional info:
Comment 1 Peter Vrabec 2006-05-03 08:05:03 EDT
I think this is a gkrellm problem, fixed in gkrellm-2.2.9-1. 

*** This bug has been marked as a duplicate of 186974 ***
Comment 2 Axel Thimm 2006-05-03 08:14:54 EDT
gkrellmd is just an example. Any package with a reserved uid/gid not found in
/etc/passwd will break the same way, and there are quite a few left in
/usr/share/doc/setup-*/uidgid.

This list is also known to keep a few bogus ones around, e.g. 93 is reserved for
exim, not distcache. Maybe the assignment of gkrellmd is bogus, too, but it is
the point of reference within fedora/redhat.

An evasive procedure to dynamically assign uid/gid would help here a lot and
allow  future extension of the reserved uids/gids w/o killing dynamically
assigned one that happen to occupy the slot.
Comment 3 Peter Vrabec 2006-05-05 06:15:19 EDT
Why do u think "useradd -r" does something with /usr/share/doc/setup-*/uidgids? 
Comment 4 Axel Thimm 2006-05-05 06:26:20 EDT
useradd does nothing with /usr/share/doc/setup-*/uidgids which might be even
considered the true issue. It will happily use a slot reserved there if the
package hasn't yet created its static user, or if the uid hasn't been stuffed
into /etc/passwd at install time.

And if /usr/share/doc/setup-*/uidgids reserves a new slot in the future it is
very likely that useradd -r will already have a dynamical user from another
package sitting on it. E.g. the setup is not future-proof.

So in order to not let this conflict happen neither with outsynced packages vs
/usr/share/doc/setup-*/uidgids or any futrure new static uids/gids it makes
sense to have useradd -r reserve dynamic udis/gids from the top of the available
range. We do have ~400 uids/gids reserved for dynamical assignment and starting
at 100 is asking for trouble now that the first 100 static id have been
assigned. Alternatively you could raise the starting uid/gid bar from 100 to 150
or 200, but starting at the top and eating through to the bottom is better IMHO.
Comment 5 Peter Vrabec 2006-05-05 09:28:08 EDT
As I know  /usr/share/doc/setup-*/uidgids is not used by any other program.   
  
The conflict may happed with static uids/gids. But packages should not use static uids/gids 
within range 100-500. Do u think 100 slots is not enought for static uids/gids? Because in that 
case I suggest to rewrite the program not to use hardcoded uids/gids. 
Comment 6 Axel Thimm 2006-05-05 13:23:34 EDT
Peter, it aren't programs I'm worried about, but humans ;)

/usr/share/doc/setup-*/uidgid is currently the only authoritative source for
static uid/gid assignments. Even if it is to be superseeded by some wiki info,
the arguments above are still valid.

As to programs using static uid/gid there is a religious war you are dropping
into. Security specialists will swear on static uid/gids for anything on the
planet while others may not care. You'll probably find more of the first kind in
Fedora/RHEL space.

This isn't a discussion I want to get into (whether static usid/gid is godd or
evil), I just take as a fact that there are already almost all slots up to 100
occupied (some hole deliberately left open) and that there is demand for more,
and that certainly more will be assigned in the very near future.
Comment 7 Axel Thimm 2007-02-07 04:24:28 EST
The merge of Core and Extras raises again the issue of too few (fixed) system
uid/gids. Since this may lead to raising the bar from 100 to something higher
please consider assigning top-down as described before to keep non-fixed system
ids out of the way.

E.g. useradd -r and groupadd -r should start at UID_MIN-1 and GID_MIN-1
respectively and work their way down.
Comment 8 Peter Vrabec 2007-03-09 09:37:16 EST
Created attachment 149686 [details]
proposed patch, any review is appreciated
Comment 9 Peter Vrabec 2007-03-12 07:26:36 EDT
Created attachment 149815 [details]
better candidate
Comment 10 Peter Vrabec 2007-03-26 10:44:09 EDT
patch applied in shadow-utils-4.0.18.1-11

Note You need to log in before you can comment on or make changes to this bug.