Red Hat Bugzilla – Bug 593683
useradd doesn't create system accounts with the same uid and gid when no groupid specified
Last modified: 2018-10-27 11:19:46 EDT
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.
Hi, Isn't the Backup/Restore use-case strong enough to restore RHEL5 behaviour ? --jer
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.
Tom I hope we don't break third-party spec files since this only affect UIDs that are reserved.
I'd agree with comment #3 - fix the shadow-utils behavior, *and* future-proof the spec files.
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.
fixed in shadow-utils-4.1.4.2-6.el6
VERIFIED using reproducer $ rpm -q shadow-utils shadow-utils-4.1.4.2-7.el6.x86_64
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.