Fedora Account System
Red Hat Associate
Red Hat Customer
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
Created attachment 1578194 [details] Output of 'rpm -Va', chrooted in the installroot
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.
Moving to upstream tracking: https://github.com/rpm-software-management/rpm/issues/882