Created attachment 1578193[details]
usertest package srpm that adds the "fake" user/group, and installs a file using that user/group name
Description of problem:
When installing packages using dnf --installroot, packages that install files with particular user/group names will use the UIDs/GIDs of the matching user/group on the host (which is executing dnf --installroot), if the user/group exists on the host.
Version-Release number of selected component (if applicable):
dnf-4.2.5-1.fc30.noarch
How reproducible:
Always
Steps to Reproduce:
1. Create test RPM which installs a file with a particular user/group name (e.g. a file called "/etc/test.txt" owned by user/group "fake").
2. Manually create a user/group with the same name on host system (e.g. "fake" user with uid/gid of 222/222).
3. Perform a minimal fedora install using dnf --installroot, including the "test.rpm" package.
3. Compare the UID/GID of the installed file(s) to the UID/GID in the installed /etc/passwd file.
Actual results:
UID/GID of the installed file(s) are the same as the host system's /etc/passwd file.
Expected results:
UID/GID of the installed file(s) match those in the installroot's /etc/passwd file.
Additional info:
This seems to happen for any user/group that exists on the host system; for example, it happens with the "unbound" user on my system (installed by unbound-libs). I've also had it happen on my Fedora 29 system, and I think on an older Fedora 28 one as well.
To test this, I created an RPM called "usertest", which adds a user/group called "fake" to the installed system and writes a file called "/etc/usertest.txt" which is owned by the "fake" user/group. When my host system has a user/group called "fake", this is the result:
> # dnf --installroot=$(pwd)/installroot --releasever=30 '@Core' usertest.rpm
> ...
> # cat /etc/passwd | grep fake
> fake:x:222:222::/home/fake:/sbin/nologin
> # cat installroot/etc/passwd | grep fake
> fake:x:997:994::/home/fake:/sbin/nologin
> # ls -n installroot/etc/usertest.txt
> -rw-r--r--. 1 222 222 13 Jun 7 14:52 installroot/etc/usertest.txt
Note above that UID/GID for the installed file has the UID/GID of the host system's "fake" user. The result of this is that when I boot the installroot system in a VM/on a machine, that file appears to be owned either by a different user/group that happens to match the "222" UID/GID, or is just the plain UID/GID (i.e. unknown).
If I 'userdel fake' on my system and re-run the dnf install, then the UID/GID of the installed file matches those in the installroot /etc/passwd file.
I don't know whether this is specifically an issue in DNF or is caused by some underlying library responsible for mapping the UIDs/GIDs to names, though.
I've attached the SRPM for the "usertest" package I have been using to test this out on my system. I've also attached an output of 'chroot installroot/ rpm -Va" , which shows some files that have mismatched user/group IDs, including the "/etc/usertest.txt" file installed by my test package.
My current work-around for this is to run a 'chroot installroot/ rpm --setugids <package>' for each package with files that have mismatched UIDs/GIDs, after the installation is complete
This is an ages old rpm-level issue, dnf is just an innocent bystander.
The problem is that glibc apparently (and understandably) caches look-ups, but doesn't offer a way to reset the cache, which would be needed for rpm as it goes in and out of chroot.