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-utils | Assignee: | Iker Pedrosa <ipedrosa> | ||||
Status: | CLOSED ERRATA | QA Contact: | Anuj Borah <aborah> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | CentOS Stream | CC: | aborah, aboscatt, agk, bstinson, cluster-maint, cseres, ipedrosa, jbrassow, jwboyer, nsoffer, pbrezina, sgadekar, teigland | ||||
Target Milestone: | rc | Keywords: | 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: |
|
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? 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 Can you provide additional information? 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? 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. @nsoffer can you help here? 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. 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. 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. Upstream PR: https://github.com/shadow-maint/shadow/pull/492 master: useradd: modify check ID range for system users - f1f1678e13aa3ae49bdb139efaa2c5bc53dcfe92 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 |
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