Bug 1472369

As noted in Bug 908447 these IDs are reserverd in the setup package.

[upr@cfproxy04 ~]$ grep 189 /usr/share/doc/setup-2.8.71/uidgid
hacluster       189     -       /               /sbin/nologin   pacemaker
haclient        -       189     -               -       pacemaker

Reassigning to polkit, which should reserve a different group id if a fixed one is required

[upr@cfproxy04 tmp]$ rpm -qp --scripts polkit-0.112-12.el7_3.x86_64.rpm
preinstall scriptlet (using /bin/sh):
getent group polkitd >/dev/null || groupadd -r polkitd
getent passwd polkitd >/dev/null || useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd
exit 0

Cannot this be a matter of non-default SYS_UID_MIN and SYS_GID_MIN
(both are set to 201 in /etc/login.defs in my installation) when
installing polkit?

(In reply to Jan Pokorný from comment #4)
> Cannot this be a matter of non-default SYS_UID_MIN and SYS_GID_MIN
> (both are set to 201 in /etc/login.defs in my installation) when
> installing polkit?

Indeed, except that it is SYS_[UG]ID_MAX set to 999; ({user,group}add -r) without a specified ID value uses the highest free one.  For example, a completely default RHEL 7.3 interactive install ends up with polkitd UID 998, GID 996 for me.

How did polkit end up with GID 189?

How exactly did you install the OS? What does (grep '[UG]ID' /etc/login.defs) output? If /etc/login.defs is modified from the OS default at all, by what?

Ok, it appears my company is using a custom version of /etc/login.defs
[upr@cfproxy04 tmp]$ cat /etc/login.defs
# This file is automatically handled by puppet (authentication) - all manual changes will be overwritten!
MAIL_DIR        /var/spool/mail
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    5
PASS_WARN_AGE   7
UID_MIN                   500
UID_MAX                   41999
GID_MIN                   500
GID_MAX                   41999
CREATE_HOME     yes
UMASK           077
USERGROUPS_ENAB yes
ENCRYPT_METHOD SHA512
MD5_CRYPT_ENAB no

It lacks the SYS_GID_MIN and SYS_UID_MIN variables.
I guess it makes this bug report irrelevant.

Is there any technical reason that the pacemaker account and group has to have a 189 UID/GID?

re [comment 8]:

Original request is here: [bug 872208].
Upstream "setup" project modification:
https://pagure.io/setup/c/37b65a18b3722cbc457cacfa9387fccfc75d3a8a

It seems that the reasoning was, amongst others, firm grounds for the
remote shell access or similar interactions in the distributed computing.

See also Fedora packaging guidelines for the particular topic:
https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation

The soft static allocation relies on distro-native login.defs file.

> Ok, it appears my company is using a custom version of /etc/login.defs

Thanks for the diagnosis.

(In reply to Przemysław Kulczycki from comment #8)
> Is there any technical reason that the pacemaker account and group has to
> have a 189 UID/GID?

Jan has pointed out to the general guidelines (in short, accounts which may access a filesystem or a similar resource over the network need to have a shared UID).  Focusing _specifically_ on pacemaker is not ultimately worthwhile; there will always be _something_ using a pre-allocated ID value, and we are now well into the 190’s in Fedora.  If it’s not pacemaker, it will be something else.


Though, reassigning to shadow-utils for consideration of one trade-off in this:

The current code (find_new_gid) is trying not to fill in “holes” in the allocated ID space (to minimize the risk of reusing a previously used ID), by finding lowest_found, the lowest allocated GID in the (SYS_GID_{MIN,MAX}) range and using lowest_found-1 if it is available.

That works perfectly fine with the default setup of SYS_GID_(MIN,MAX) = (201,999), with statically allocated GIDs < 201, and lowest_found in the 990s.

But, with the values unspecified as in comment #7, SYS_GID_MIN defaults to 101; i.e. if any package with a statically allocated GID in the [101,200] range is installed (in this case, certainly systemd-journal, GID 190), lowest_found ≤ 190, i.e. the code will start allocating dynamic GIDs overlapping the statically-allocated range even if there are hundreds of higher GID values available.

It seems that when trying to allocate static ID values from bottom up and dynamic from top down, skipping the vast majority of the dynamic area, i.e. increasing, not decreasing, the risk of collision, seems suboptimal and not really worth the risk of reusing a previously allocated value.

I can’t think of a reasonable fix or whether this should just be called a misconfiguration; we could perhaps stop the lowest_found search at the highest “hole” of N (64?) free GIDs, regardless of GIDs allocated below, but that’s also an ugly a fragile heuristic. Changing the default for SYS_GID_MIN is out of the question I guess.

I actually believe that adding the suggested heuristic would be nice improvement. I mean the 'skipping holes' behavior is just a heuristic as well so adding one more hint should not harm anything.

Perhaps the hole size could be even configurable, but that would require upstream acceptance for adding a new configuration value.

This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

I am closing the bug for now as I do not think there is any customer request behind it. There is a duplicate Fedora bug 958842 and if anywhere it should be developed in Fedora and upstream first.