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.
Bug 2004911 - useradd warning: sanlock's uid 179 outside of the SYS_UID_MIN 201 and SYS_UID_MAX 999 range.
Summary: useradd warning: sanlock's uid 179 outside of the SYS_UID_MIN 201 and SYS_UID...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: shadow-utils
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Iker Pedrosa
QA Contact: Anuj Borah
URL:
Whiteboard: sync-to-jira review
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-09-16 12:23 UTC by Sandro Bonazzola
Modified: 2022-11-15 13:00 UTC (History)
13 users (show)

Fixed In Version: shadow-utils-4.9-4.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 11:14:40 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
jenkins log showing the issue (3.61 MB, text/plain)
2021-09-16 12:23 UTC, Sandro Bonazzola 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-97531 0 None None None 2021-09-18 10:15:25 UTC
Red Hat Issue Tracker SSSD-4087 0 None None None 2021-12-08 12:30:58 UTC
Red Hat Product Errata RHBA-2022:8289 0 None None None 2022-11-15 11:14:43 UTC

Description Sandro Bonazzola 2021-09-16 12:23:38 UTC 
Created attachment 1823558 [details]
jenkins log showing the issue

While building oVirt Node (so installing everything in a clean root) yum installation of sanlock reports:

useradd warning: sanlock's uid 179 outside of the SYS_UID_MIN 201 and SYS_UID_MAX 999 range.

This didn't happen while building oVirt Node based on CentOS Stream 8
Comment 2 David Teigland 2021-10-19 14:59:23 UTC 
10 years ago sanlock began using useradd with UID/GID 179.  Looking back at old email I couldn't find where that number came from.  I wonder if some policy on ids changed recently which triggered these warnings.  Should I change the spec file to use a different number, and if so how do I pick one?
Comment 3 Iker Pedrosa 2021-10-20 07:26:10 UTC 
This new behaviour was added to useradd two years ago and it wasn't backported to CentOS Stream 8, but it arrived to CentOS Stream 9 when I rebased shadow-utils to the latest version. For the moment I wouldn't be much preoccupied as it is only a warning, but if you want to be on the safe side you can change the UID to something between SYS_UID_MIN (201) and SYS_UID_MAX (999) as defined in /etc/login.defs. Another option would be to stop hardcoding the UID (-u option) when creating the user and let the system decide which number to assign. This last option triggers a question: why are you hardcoding this UID number?

Link to the commit: https://github.com/shadow-maint/shadow/commit/00e629c0ba4b3e90b61df6dd220e5b56e2159284
Comment 4 Iker Pedrosa 2021-11-05 08:52:01 UTC 
Can you provide additional information?
Comment 5 David Teigland 2021-11-05 18:01:15 UTC 
I'm happy to stop hardcoding 179 if that's common practice.  I wonder if there could be compatibility issues around changing this, especially if done between RHEL minor updates.  I'm curious if RHV could be sensitive to a change, and if they have any dependencies on the 179 value?
Comment 6 Iker Pedrosa 2021-11-08 08:04:47 UTC 
Yes, many packages create their system user without hardcoding the UID, but instead using the create system account (-r) option. I'm not completely sure about the RHV and UID dependency though, so I'd tried to avoid changing that between minor releases and do it only for major releases, so that if anything happens the problems appears first in a testing environment rather than in a production environment.
Comment 7 Sandro Bonazzola 2021-11-08 10:35:05 UTC 
@nsoffer can you help here?
Comment 8 Nir Soffer 2021-11-08 15:05:44 UTC 
I'm not sure changing sanlock user id is safe, it may already be used on 
remote storage.

Since we use shared storage, sanlock uid must be the same on all hosts 
accessing the storage, just like vdsm uid (36) and qemu gid (36).

I think in this case the system must be adapted to accept existing software,
not the other way around.
Comment 9 Iker Pedrosa 2021-11-09 09:02:42 UTC 
Okay, I think I overlooked something very important. The only option to take into account for system accounts is SYS_UID_MAX (999). Thus, UIDs between 0 and 999 are system account. SYS_UID_MIN (201) should not be taken into account when checking the range.

For the moment this is only a warning so this shouldn't stop the normal behaviour of the system. Taking that into account I'm lowering the priority.
Comment 10 Cristian Seres 2021-12-03 13:38:23 UTC 
There is similar error when installing httpd (2.4.48-17) with yum:
useradd warning: apache's uid 48 outside of the SYS_UID_MIN 201 and SYS_UID_MAX 999 range.

I was about to create a separate bug for that, but I'll skip it for now as this seems to be already known issue.
Comment 11 Iker Pedrosa 2022-01-04 13:31:31 UTC 
Upstream PR:
    https://github.com/shadow-maint/shadow/pull/492
Comment 12 Iker Pedrosa 2022-01-20 11:26:44 UTC 
master:
    useradd: modify check ID range for system users - f1f1678e13aa3ae49bdb139efaa2c5bc53dcfe92
Comment 19 errata-xmlrpc 2022-11-15 11:14:40 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (shadow-utils bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8289
Note You need to log in before you can comment on or make changes to this bug.