Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 593683 - useradd doesn't create system accounts with the same uid and gid when no groupid specified
Summary: useradd doesn't create system accounts with the same uid and gid when no grou...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: shadow-utils
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Peter Vrabec
QA Contact: Miroslav Vadkerti
Depends On: 594084 594092 594155 594206 594256 594305 594342 594394 594395 594398 594399 594402 594405
Blocks: 580448
TreeView+ depends on / blocked
Reported: 2010-05-19 13:48 UTC by Ondrej Vasik
Modified: 2018-10-27 15:19 UTC (History)
14 users (show)

Fixed In Version: shadow-utils-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-07-02 19:51:52 UTC
Target Upstream Version:

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

Description Ondrej Vasik 2010-05-19 13:48:44 UTC
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 16:15:28 UTC
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 17:25:30 UTC
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 18:08:33 UTC
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 12:56:43 UTC
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 13:43:26 UTC

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


Comment 6 Peter Vrabec 2010-05-20 15:17:06 UTC
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 15:19:34 UTC
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 15:24:59 UTC
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 15:26:07 UTC
I'd agree with comment #3 - fix the shadow-utils behavior, *and* future-proof the spec files.

Comment 11 Tom Lane 2010-05-20 15:46:17 UTC
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 20:00:33 UTC
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 09:53:37 UTC
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 13:47:27 UTC
fixed in shadow-utils-

Comment 18 Michal Haško 2010-06-17 13:11:47 UTC
VERIFIED using reproducer

$ rpm -q shadow-utils

Comment 19 releng-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.

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