Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
useradd doesn't create create system accounts with same uid and gid. This is regression from RHEL-5 and blocker for GA.
At the moment
/usr/sbin/useradd -c "Privilege-separated SSH" -u %{sshd_uid} \
-s /sbin/nologin -r -d /var/empty/sshd sshd 2> /dev/null || :
Just creates the sshd account with uid 74 - but with dynamically allocated system groupid (<500). It should create it with gid 74.
Note - second - correct - way to create statically allocated just works:
getent group qemu >/dev/null || groupadd -g 107 -r qemu
getent passwd qemu >/dev/null || \
useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \
-c "qemu user" qemu
How reproducible:
Always
Steps to Reproduce:
1. Try to create system user
#/usr/sbin/useradd -c "TryIt" -u 194 -s /sbin/nologin -r -d / tryitd
2.
getent passwd
Actual results:
Something like
tryitd:x:194:482:TryIt:/:/sbin/nologin
Expected results:
tryitd:x:194:194:TryIt:/:/sbin/nologin
Additional info:
This has to be resolved before RHEL-6 GA, otherwise we will have no chance to change those dynamically allocated groups...
We need to make our mind since I don't want to hit bug #515667 again. :)
Note, that according to guidance[1], this should be used:
getent group GROUPNAME >/dev/null || groupadd -r GROUPNAME
getent passwd USERNAME >/dev/null || \
useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin \
-c "Useful comment about the purpose of this account" USERNAME
And if it is used this way ^ everything will work fine.
-------
[1] https://fedoraproject.org/wiki/Packaging:UsersAndGroups
I'd prefer that the 'use the same GID unless specified' behavior be restored; is there some reason that conflicts with the minimum system range change?
Peter is right that if you use that guidance, everything is fine - however - many system accounts with reserved static uidgid pairs don't follow that guideline - and they got dynamically assigned group id at the moment.
I think the best way is to restore the old behaviour for RHEL-6 and to do a tracker bugzilla for Fedora - to make the system user account correctly again. From my check (common RHEL-6 installation) there were ~7 system accounts affected ... sshd (openssh-server), vcsa (MAKEDEV), mysql (mysql), rpcuser (nfs-utils) , nscd (glibc) , haldaemon (hal), gdm (gdm) ... but I haven't checked all of the reserved uidgid's creation. I'm sure there are more ...
Another accounts with wrong user creation: xfs (xorg-x11-xfs), mailnull (sendmail) , smmsp (sendmail), apache (httpd), nut (nut) , prelude-manager (prelude-manager), snortd (snort) , webalizer (webalizer) , radvd (radvd), fax (mgetty), distcache (distcache) ...
PolicyKit package is now dead (and polkit doesn't seem to use reserved uidgid) , dovecot doesn't use the reserved uidgid at all from what I have seen in spec file...
Hopefully that covers all affected accounts.
changing keyword from regression->tracking. We need to fix 13 spec files in RHEL.
I think fixing spec files is cleaner solution. Sure, it will be possible to restore previous behaviour but it will result in:
1. divergence from upstream
2. possible problems with mixing static/dynamic IDs
You mean 13 *known* problems, among the set of packages that Red Hat ships. This is likely to also break a lot of third-party spec files. I'm of the opinion that reverting useradd's behavior is the only really safe solution; not to mention that it's 1/13th as much package churn.
Re comment #9: don't think we should count on it. For instance, MySQL AB^H^H^HSun^H^H^HOracle ship their own RPMs for mysql on RHEL. The latest version of that specfile that I have doesn't seem to be trying to assign reserved GIDs, but that's an old version --- since then it's quite possible they'd have copied our file so as not to create a hiccup when moving between their install and ours.
I don't mind future-proofing the spec files to specify the GID they want explicitly, but I think this ought to be the blocker bug not the other 13.
I'm not surprised that the Fedora community doesn't care much about such things but RHEL customers will. So why not keep compatibility as much as possible - it doesn't look to difficult.
If useradd -r -u is used, useradd should check whether the GID with the number as the requested UID is still available, if yes then it should take it, otherwise grab a free one which is in the range of dynamically assigned IDs.
That way no change has to be made to existing spec files - that's quite important for all VAR's and third party developers.
Created attachment 415631[details]
patch
OK, so in case people
1. don't follow package guidance
&&
2. use reserved UIDs/GIDs
There is this "special" patch. It behaves as Simon said.
I suggest keeping spec file bugs open and I would also ask upstream how they like this behaviour before I commit the patch into Fedora.
VERIFIED using reproducer
$ rpm -q shadow-utils
shadow-utils-4.1.4.2-7.el6.x86_64
Comment 19releng-rhel@redhat.com
2010-07-02 19:51:52 UTC
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Description of problem: useradd doesn't create create system accounts with same uid and gid. This is regression from RHEL-5 and blocker for GA. At the moment /usr/sbin/useradd -c "Privilege-separated SSH" -u %{sshd_uid} \ -s /sbin/nologin -r -d /var/empty/sshd sshd 2> /dev/null || : Just creates the sshd account with uid 74 - but with dynamically allocated system groupid (<500). It should create it with gid 74. Note - second - correct - way to create statically allocated just works: getent group qemu >/dev/null || groupadd -g 107 -r qemu getent passwd qemu >/dev/null || \ useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \ -c "qemu user" qemu How reproducible: Always Steps to Reproduce: 1. Try to create system user #/usr/sbin/useradd -c "TryIt" -u 194 -s /sbin/nologin -r -d / tryitd 2. getent passwd Actual results: Something like tryitd:x:194:482:TryIt:/:/sbin/nologin Expected results: tryitd:x:194:194:TryIt:/:/sbin/nologin Additional info: This has to be resolved before RHEL-6 GA, otherwise we will have no chance to change those dynamically allocated groups...