Bug 1718146 - dnf --installroot packages write files using uids/gids from outside installroot
Summary: dnf --installroot packages write files using uids/gids from outside installroot
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 30
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-07 05:24 UTC by Aidan Smith
Modified: 2020-07-14 21:11 UTC (History)
14 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-10-15 08:59:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
usertest package srpm that adds the "fake" user/group, and installs a file using that user/group name (6.39 KB, application/x-rpm)
2019-06-07 05:24 UTC, Aidan Smith
no flags Details
Output of 'rpm -Va', chrooted in the installroot (542 bytes, text/plain)
2019-06-07 05:27 UTC, Aidan Smith
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github rpm-software-management rpm issues 882 0 None open Rpm chroot operations use user/group info from the host 2020-07-15 17:58:21 UTC

Description Aidan Smith 2019-06-07 05:24:59 UTC
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

Comment 1 Aidan Smith 2019-06-07 05:27:07 UTC
Created attachment 1578194 [details]
Output of 'rpm -Va', chrooted in the installroot

Comment 2 Panu Matilainen 2019-06-07 06:23:12 UTC
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.

Comment 3 Panu Matilainen 2019-10-15 08:59:18 UTC
Moving to upstream tracking: https://github.com/rpm-software-management/rpm/issues/882


Note You need to log in before you can comment on or make changes to this bug.