Bug 190523

I think this is a gkrellm problem, fixed in gkrellm-2.2.9-1. 

*** This bug has been marked as a duplicate of 186974 ***

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.

Why do u think "useradd -r" does something with /usr/share/doc/setup-*/uidgids? 

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.

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. 

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.

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.

Created attachment 149686 [details]
proposed patch, any review is appreciated

Created attachment 149815 [details]
better candidate

patch applied in shadow-utils-4.0.18.1-11