What were you trying to do that didn't work?
A customer is building a custom package having files configured with S_ISUID/S_ISGID bits.
When rpmfilesStat() executes, the following warning is seen:
group XXX does not exist - using root
This is because the customer is also having his user and group in a AD backend, not as local user/group.
It appears that code changed with RHEL10 compared to RHEL9:
RHEL10 code only checks for the group in /etc/group (and user in /etc/passwd) while until RHEL9 included, NSS functions were used, e.g.:
65 int rpmugGid(const char * thisGname, gid_t * gid) 66 { : 92 grent = getgrnam(thisGname); :
vs RHEL10:
186 int rpmugGid(const char * thisGname, gid_t * gid) 187 { : 197 if (lookup_num(grpfile(), thisGname, 0, 2, &id)) 198 return -1; : 41 static const char *grpfile(void) 42 { 43 return getpath("group", "/etc/group", &rpmug->grppath); 44 }
This is new and due to commit below:
commit f3eaeeb7341085e1850e914350cf1f33d538320d Author: Panu Matilainen <pmatilai@redhat.com> Date: Thu May 4 11:10:12 2023 +0300 Make user/group info reliable operation across chroot There's no telling what sort of caching getpwnam() and friends perform behind the scenes, and worse, there's no way to explicitly reset those caches. This can lead to chrooted operations using user/group data from the host, which is simply wrong. Do our own parsing of /etc/passwd and /etc/group to fix. Besides the chroot matter, we then only ever lookup local system users and groups and not something from eg network name services. We cannot reliably do NSS in a chroot because doing so would require relying on binaries in the chroot, which in itself is completely unreliable. NSS is also unreliable in various rescue mode situations. Bottom line, local files are the only ones that can be guaranteed for rpm operation, and this change basically enforces that. Technically we should track chroot status for each lookup and flush the cache if the state changed, but this is an internal API and rpm usages only ever call it from one side of the chroot for a given operation. Fixes: #882, #1789
I understand that there was an issue with chroots, but in normal conditions it seems overkill to me: many customers make use of remote users and groups, and, even if having non-local users and groups for services is not recommended, it's still supported.
What is the impact of this issue to you?
Customer cannot install his custom package properly.
Please provide the package NVR for which the bug is seen:
rpm-4.19.1.1-12.el10
How reproducible is this bug?:
Always
Steps to reproduce
- Create a package with a non-local user and group for some file
Expected results
Installing goes fine
Actual results
File gets "root:root" ownership
- links to