RPMs have scripts that get run at various stages of install.  These 
scripts will call useradd/groupadd in various ways.

$ rpm -q --scripts <package>

This will allow you to read some of the scripts associated with 
installed packages.  I took a look at some of them to get some answers 
for you.

So for instance, from bind:

     /usr/sbin/groupadd -g 25 -f -r named >/dev/null 2>&1 || :;
     /usr/sbin/useradd  -u 25 -r -N -M -g named -s /sbin/nologin -d 
/var/named -c Named named >/dev/null 2>&1 || :;

You can see SL/RH have manually specified a UID/GID of 25.

For dhcpd:

     getent group dhcpd >/dev/null || groupadd --force --gid 177 
--system dhcpd
     if ! getent passwd dhcpd >/dev/null ; then
         if ! getent passwd 177 >/dev/null ; then
           useradd --system --uid 177 --gid dhcpd --home / --shell 
/sbin/nologin --comment "DHCP server" dhcpd
         else
           useradd --system --gid dhcpd --home / --shell /sbin/nologin 
--comment "DHCP server" dhcpd
         fi
     fi


It's hardcoded at 177.  These packages are both in the main SL/RH 
repositories, so take a package from sl-extras, for example docker:

     getent group docker > /dev/null || /usr/sbin/groupadd -r docker

Or EPEL, statsd:

     getent group statsd >/dev/null || groupadd -r statsd
     getent passwd statsd >/dev/null || \
         useradd -r -g statsd -d / -s /sbin/nologin \
         -c "statsd daemon user" statsd
     exit 0


The UID/GID is not hard coded in these packages, instead they use the 
"-r" option to useradd/groupadd to specify that they are system 
applications:

        -r, --system
            Create a system account.

            System users will be created with no aging information in 
/etc/shadow, and their numeric identifiers are chosen in the 
SYS_UID_MIN-SYS_UID_MAX range,
            defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and 
their GID counterparts for the creation of groups).


So I guess the direct answer to your question is the "-r" option to 
useradd/groupadd, but some system daemons have their GIDs/UIDs 
hardcoded.  It is partially a gentleman's agreement, but since it's 
essentially a gentleman's agreement among the repository admins to make 
sure "-r" is used and not to hard code unless you are the original 
distribution manager, it's probably nearly always abided by.  Since "-r" 
does other things (like not creating a home directory or treating 
/etc/shadow and /etc/passwd differently), a repository admin will want 
to use it anyway for security and general cleanliness purposes.

-Brad


> So, as I understand this, login.defs is only used by useradd (which
> I assume system-config-users must invoke)?
>
> What is to govern (other than perhaps some sort of gentleman's
> agreement in the app world) what UID/GID an application decides
> to grab upon install?
>
> I used the ntop app as an example in a previous post under the
> previous thread and noted that it grabbed UID:103, GID:160.
> What's to prevent an app from grabbing a UID and GID > 500
> (or 1000 in newer releases)?
>
> BTW, as an aside, if you haven't discovered and installed ntop
> (epel repo), I highly recommend it.  An amazing admin net tool
> that's web based and I'm still learning what all it can do and
> display.
>
> - Larry
>