Bug 2036632

Summary: rpm shows bogus verify failures with --root
Product: [Fedora] Fedora Reporter: Zbigniew Jędrzejewski-Szmek <zbyszek>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 37CC: packaging-team-maint, pmatilai, pmoravco, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-04 10:15:59 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:

Description Zbigniew Jędrzejewski-Szmek 2022-01-03 13:09:50 UTC
Description of problem:
I needed to install a package onto an arm64 image, from a amd64 host.
To verify the installation, I executed 'rpm --root=… -V …', and was surprised
that UG discrepancy was reported for all files. It turns out that rpmverify
reports that for any package:

$ rpm --root /tmp/root -V bash
error: Failed to dlopen /usr/lib64/rpm-plugins/selinux.so /usr/lib64/rpm-plugins/selinux.so: cannot open shared object file: No such file or directory
error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /usr/lib64/rpm-plugins/systemd_inhibit.so: cannot open shared object file: No such file or directory
.....UG..  c /etc/skel/.bash_logout
.....UG..  c /etc/skel/.bash_profile
.....UG..  c /etc/skel/.bashrc
.....UG..    /usr/bin/bashbug-64
.....UG..    /usr/bin/bg
.....UG..    /usr/bin/cd
.....UG..    /usr/bin/command
.....UG..    /usr/bin/fc
.....UG..    /usr/bin/fg
…


But there is no problem with the ownership:
$ stat /tmp/root/usr/bin/fg 
  File: /tmp/root/usr/bin/fg
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
…


Hmm, the same result occurs for the native architecture:
$ rpm -V --root=/var/lib/machines/rawhide bash   
.....UG..  c /etc/skel/.bash_logout
.....UG..  c /etc/skel/.bash_profile
.....UG..  c /etc/skel/.bashrc
.....UG..    /usr/bin/bashbug-64

$ ls -l /var/lib/machines/rawhide/usr/bin/bashbug-64 
-rwxr-xr-x 1 root root 7063 Nov  5 12:30 /var/lib/machines/rawhide/usr/bin/bashbug-64

Version-Release number of selected component (if applicable):
rpm-4.17.0-1.fc35.x86_64

How reproducible:
Seems deterministic.

Steps to Reproduce:
1. rpm -V --root=/path/to/image bash

Actual results:
UG mismatch reported

Expected results:
No output

Comment 1 Panu Matilainen 2022-01-04 13:29:01 UTC
Possibly same as/related to https://github.com/rpm-software-management/rpm/issues/1789

Comment 2 Panu Matilainen 2022-01-04 13:38:29 UTC
Got any convenient pointer to image(s) that I could use for testing? I'm not able to reproduce with local chroot install of the same arch...

Comment 3 Zbigniew Jędrzejewski-Szmek 2022-01-04 14:08:30 UTC
$ sudo dnf '--disablerepo=*' --enablerepo=fedora --enablerepo=updates --releasever=35 --installroot=/var/tmp/f35 --setopt install_weak_deps=False install bash rpm -y
$ rpm -V --root=/var/tmp/f35 bash                
.....UG..  c /etc/skel/.bash_logout
.....UG..  c /etc/skel/.bash_profile
.....UG..  c /etc/skel/.bashrc
.....UG..    /usr/bin/alias

I don't think https://github.com/rpm-software-management/rpm/issues/1789 is related — here the image is
all installed by the time 'rpm -V' is executed, so all users are defined.

$ sudo chroot /var/tmp/f35 rpm -V bash
(nothing, i.e. all good)
$ sudo chroot /var/tmp/f35 id 0       
uid=0(root) gid=0(root) groups=0(root)

So it's something about crossing --root being used.

Comment 4 Panu Matilainen 2022-01-04 14:21:14 UTC
Oh... now I see it - you're running verify as a regular user, which doesn't generally work. In older versions, you'd just get "error: Unable to change root directory: Operation not permitted" instead, which is annoying but the current behavior is misleading which tends to be worse.

Comment 5 Panu Matilainen 2022-01-04 14:23:58 UTC
(hit enter too soon...)

This happens because rpm now uses user namespace for performing the chroot if necessary (ie running as a regular user) but that messes up the user/group situation :-/

Comment 6 Panu Matilainen 2022-01-04 14:47:27 UTC
Oh, and for full disclosure, rpm -V with --root is not reliable in any case, even as root, never was. It uses the user info from the "host" which is sometimes what you want (think anaconda) and at others it's just plain wrong.

Comment 7 Ben Cotton 2022-11-29 17:35:32 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 8 Zbigniew Jędrzejewski-Szmek 2022-11-29 22:08:35 UTC
No change with rpm-4.18.0-1.fc37.x86_64.

I really think rpm should either implement the operation correctly or refuse it altogether.
Partial operation just leads to user frustration.

Comment 9 Panu Matilainen 2023-07-04 10:15:59 UTC
This is now fixed upstream and will land in Fedora with rpm 4.19 beta.