Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 593683 - useradd doesn't create system accounts with the same uid and gid when no groupid specified
useradd doesn't create system accounts with the same uid and gid when no grou...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: shadow-utils (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Peter Vrabec
Miroslav Vadkerti
: Tracking
Depends On: 594084 594092 594155 594206 594256 594305 594342 594394 594395 594398 594399 594402 594405
Blocks: 580448
  Show dependency treegraph
Reported: 2010-05-19 09:48 EDT by Ondrej Vasik
Modified: 2018-10-27 11:19 EDT (History)
14 users (show)

See Also:
Fixed In Version: shadow-utils-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-02 15:51:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch (1023 bytes, patch)
2010-05-21 05:53 EDT, Peter Vrabec
no flags Details | Diff

  None (edit)
Description Ondrej Vasik 2010-05-19 09:48:44 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:

Steps to Reproduce:
1. Try to create system user
#/usr/sbin/useradd -c "TryIt" -u 194 -s /sbin/nologin -r -d / tryitd
getent passwd

Actual results:
Something like

Expected results:

Additional info:
This has to be resolved before RHEL-6 GA, otherwise we will have no chance to change those dynamically allocated groups...
Comment 1 Peter Vrabec 2010-05-19 12:15:28 EDT
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
Comment 2 Bill Nottingham 2010-05-19 13:25:30 EDT
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?
Comment 3 Ondrej Vasik 2010-05-19 14:08:33 EDT
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 ...
Comment 4 Ondrej Vasik 2010-05-20 08:56:43 EDT
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.
Comment 5 Jeremy Eder 2010-05-20 09:43:26 EDT

Isn't the Backup/Restore use-case strong enough to restore RHEL5 behaviour ?

Comment 6 Peter Vrabec 2010-05-20 11:17:06 EDT
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
Comment 7 Tom Lane 2010-05-20 11:19:34 EDT
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.
Comment 9 Peter Vrabec 2010-05-20 11:24:59 EDT
Tom I hope we don't break third-party spec files since this only affect UIDs that are reserved.
Comment 10 Bill Nottingham 2010-05-20 11:26:07 EDT
I'd agree with comment #3 - fix the shadow-utils behavior, *and* future-proof the spec files.
Comment 11 Tom Lane 2010-05-20 11:46:17 EDT
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.
Comment 12 Simon Matter 2010-05-20 16:00:33 EDT
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.
Comment 13 Peter Vrabec 2010-05-21 05:53:37 EDT
Created attachment 415631 [details]

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.
Comment 15 Peter Vrabec 2010-05-21 09:47:27 EDT
fixed in shadow-utils-
Comment 18 Michal Haško 2010-06-17 09:11:47 EDT
VERIFIED using reproducer

$ rpm -q shadow-utils
Comment 19 releng-rhel@redhat.com 2010-07-02 15:51:52 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.