Bug 2004911

Summary: useradd warning: sanlock's uid 179 outside of the SYS_UID_MIN 201 and SYS_UID_MAX 999 range.
Product: Red Hat Enterprise Linux 9 Reporter: Sandro Bonazzola <sbonazzo>
Component: shadow-utilsAssignee: Iker Pedrosa <ipedrosa>
Status: CLOSED ERRATA QA Contact: Anuj Borah <aborah>
Severity: unspecified Docs Contact:
Priority: medium    
Version: CentOS StreamCC: aborah, aboscatt, agk, bstinson, cluster-maint, cseres, ipedrosa, jbrassow, jwboyer, nsoffer, pbrezina, sgadekar, teigland
Target Milestone: rcKeywords: Regression, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sync-to-jira review
Fixed In Version: shadow-utils-4.9-4.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-11-15 11:14:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
jenkins log showing the issue none

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