dnf5 not raising error until the end when running with no privileges

[mattiaverga]

Running dnf upgrade foo immediately stops with an error warning the user that the command needs to be executed in privileged mode (sudo or root).

Running dnf5 upgrade foo instead performs all the tasks, downloads the update and then fails with a permission denied.

[ppisar]

Already reported in Fedora Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=2217842.

[ppisar]

I believe that DNF4 lies. Checking for EUID is not a proper test because in the world of SELinux a nonsuperuser can have plenty of other ways to obtain required privileges. Especially when multi-level security is employed.

DNF5 could temporarily acquire its lock before a transaction test. That would prevent users without a write access to a DNF database to continue in the operations which are supposed to modify the system (install, upgrade, remove, etc.).

However, I believe that DNF5 should not deny users from performing a dependency resolution which happens before the transaction check. Querying DNF5 for action it would perform, in a sense of "dnf5 --assumeno ..." is a legitimate operation.

[j-mracek]

However, I believe that DNF5 should not deny users from performing a dependency resolution which happens before the transaction check. Querying DNF5 for action it would perform, in a sense of "dnf5 --assumeno ..." is a legitimate operation.

We can only allow that if we will be able to allow cache sharing between users. If dnf5 --assumeno upgrade and sudo dnf5 -y upgrade results in double cache download and processing to solv file then user might get upset.

[jan-kolarik]

Related existing issue: #337.

[jan-kolarik]

I would like to discuss various ways to accomplish this task.

Here are some of my thoughts on the topic:

• How to check 🔒
  • Try to acquire a transaction write lock (instead of the current euid approach)
  • Allow user to pass a specific parameter explicitly ("I know I am not root, I just want to resolve deps")
• When to check 🕑
  • After the goal is resolved
  • Before the command is executed (after parsing)
  • At the beginning of the transaction run method
• How to notify the user 🔔
  • For each command requiring elevated privileges
  • After the transaction table is printed

As we seem to have reached a consensus for the default DNF5 behavior to be strict, I prefer the check to be performed before command processing (and before metadata is downloaded). I also support @ppisar's suggestion of switching to the approach of acquiring the lock.

[j-mracek]

How to check
I believe that the new mechanism should differ from implementation in DNF4. I don't think that I should use root privilege at all if I have write permission for RPMDB at transaction destination. For example if I create new installroot in my home why I should require any additional permission for installing software into it? I am suggesting to verify whether I have a write permission for RPMDB.

When to check
I am suggesting to check permissions as soon as possible (before refresh of repository metadata). But make it conditionally. Like dnf5 install --downloadonly --destdir does not require any extra permission, because the command will only download package to destdir. But for dnf5 install --downloadonly the intentions are not clear. If the command is followed by dnf5 install --cacheonly then the user has a problem because metadata and downloaded packages are stored at different location.

Postponing of the check after metadata are downloaded might provide some user experience complains, because metadata might be re-downloaded also for the root user.

How to notify the user
What about DNF5 exception (not a library exception).

[m-blaha]

Hm, it might not be that easy. It looks like sometimes rpm is not able to complete the transaction in an empty, writable installroot without root permissions. It fails on Unpack error:

$ dnf5 install filesystem --installroot=/tmp/IR --use-host-config
Repositories loaded.
Package                         Arch    Version                    Repository        Size
Installing:                                                                              
 filesystem                     x86_64  3.18-6.fc39                fedora       106.0   B
Installing dependencies:                                                                 
 fedora-gpg-keys                noarch  39-1                       fedora       123.2 KiB
 fedora-release                 noarch  39-36                      updates        0.0   B
 fedora-release-common          noarch  39-36                      updates       18.9 KiB
 fedora-release-identity-basic  noarch  39-36                      updates      666.0   B
 fedora-repos                   noarch  39-1                       fedora         4.5 KiB
 setup                          noarch  2.14.4-1.fc39              fedora       720.3 KiB

Transaction Summary:
 Installing:        7 packages

------------------------- 8< ----------------------------------

The key was successfully imported.
[1/9] Verify package files                       100% | 170.0   B/s |   7.0   B |  00m00s
>>> Running pre-transaction scriptlet: filesystem-0:3.18-6.fc39.x86_64
>>> Stop pre-transaction scriptlet: filesystem-0:3.18-6.fc39.x86_64
[2/9] Prepare transaction                        100% | 304.0   B/s |   7.0   B |  00m00s
[3/9] Installing fedora-release-identity-basic-0 100% | 112.8 KiB/s | 924.0   B |  00m00s
[4/9] Installing fedora-gpg-keys-0:39-1.noarch   100% |   6.3 MiB/s | 167.6 KiB |  00m00s
[5/9] Installing fedora-repos-0:39-1.noarch      100% |   5.2 MiB/s |   5.3 KiB |  00m00s
[6/9] Installing fedora-release-common-0:39-36.n 100% |   2.5 MiB/s |  23.1 KiB |  00m00s
[7/9] Installing fedora-release-0:39-36.noarch   100% |   0.0   B/s | 124.0   B |  00m00s
[8/9] Installing setup-0:2.14.4-1.fc39.noarch    100% |  28.3 MiB/s | 725.7 KiB |  00m00s
>>> Running post-install scriptlet: setup-0:2.14.4-1.fc39.noarch
>>> Stop post-install scriptlet: setup-0:2.14.4-1.fc39.noarch
[9/9] Installing filesystem-0:3.18-6.fc39.x86_64 100% |   1.0 MiB/s | 212.4 KiB |  00m00s
>>> Unpack error: filesystem-0:3.18-6.fc39.x86_64

Transaction failed: Rpm transaction failed.

When you try to do similar thing using only rpm and downloaded packages:

rpm -U --root /tmp/IR filesystem-3.18-6.fc39.x86_64.rpm setup-2.14.4-1.fc39.noarch.rpm  fedora-release-39-36.noarch.rpm fedora-release-common-39-36.noarch.rpm fedora-repos-39-1.noarch.rpm fedora-release-identity-basic-39-36.noarch.rpm fedora-gpg-keys-39-1.noarch.rpm 
warning: filesystem-3.18-6.fc39.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 18b8e74c: NOKEY
error: unpacking of archive failed on file /var/spool/mail: cpio: chown failed - Device or resource busy
error: filesystem-3.18-6.fc39.x86_64: install failed

Btw, we already have an old RFE for this: https://bugzilla.redhat.com/show_bug.cgi?id=1878057

[ppisar]

Would it be possible for DNF5 to print the detailed cause why the transaction faile?. I.e. to follow "Transaction failed: Rpm transaction failed." with "unpacking of archive failed on file /var/spool/mail: cpio: chown failed - Device or resource busy"?

[j-mracek]

There is even not any lead in dnf5.log

[hiredman]

I am running into this(I think) when trying to populate a container built from scratch using buildah

[heyakyra]

#849 (comment)

Hm, it might not be that easy. It looks like sometimes rpm is not able to complete the transaction in an empty, writable installroot without root permissions. It fails on Unpack error:

[…]

Btw, we already have an old RFE for this: https://bugzilla.redhat.com/show_bug.cgi?id=1878057

I get these Unpack error: messages inside my toolbox/podman containers. Is there a workaround to resolve it?

[jan-kolarik]

#849 (comment)

Hm, it might not be that easy. It looks like sometimes rpm is not able to complete the transaction in an empty, writable installroot without root permissions. It fails on Unpack error:
[…]
Btw, we already have an old RFE for this: https://bugzilla.redhat.com/show_bug.cgi?id=1878057

I get these Unpack error: messages inside my toolbox/podman containers. Is there a workaround to resolve it?

Sorry for late reply, but more details about the unpack error should be now reported in recent dnf5 packages since this PR, should be present since 5.2.7.0

[heyakyra]

Edit: I was able to fix this by simply removing the plugin sudo dnf remove rpm-plugin-ima which also removed ima-evm-utils and upgrading works without a problem.

Thanks, but now I'm hitting this from within my toolbx containers:

[  1/557] zlib-ng-compat-devel-0:2.1.7-3.fc41.x86_64                                                                                                                       100% |   0.0   B/s |   0.0   B |  00m00s
>>> Already downloaded                                                                                                                                                     100% |   0.0   B/s |   0.0   B |  00m00s
[  1/558] zvbi-0:0.2.42-1.fc41.x86_64                                                                                                                                      100% |   0.0   B/s |   0.0   B |  00m00s
>>> Already downloaded                                                                                                                                                     100% |   0.0   B/s |   0.0   B |  00m00s
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[558/558] Total                                                                                                                                                            100% |   0.0   B/s |   0.0   B |  00m00s
Running transaction
[   1/1108] Verify package files                                                                                                                                           100% | 215.0   B/s | 558.0   B |  00m03s
>>> Running pre-transaction scriptlet: crypto-policies-0:20241029-1.git8baf557.fc41.noarch
>>> Finished pre-transaction scriptlet: crypto-policies-0:20241029-1.git8baf557.fc41.noarch
>>> [RPM] Unable to get systemd shutdown inhibition lock: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the rep
[   2/1108] Prepare transaction                                                                                                                                            100% | 867.0   B/s |   1.1 KiB |  00m01s
[   3/1108] Upgrading libgcc-0:14.2.1-3.fc41.x86_64                                                                                                                        100% | 269.8 MiB/s | 276.3 KiB |  00m00s
>>> [RPM] ima: could not apply signature on '/lib64/libgcc_s-14-20240912.so.1;674626bb': Operation not permitted
>>> [RPM] Plugin ima: hook fsm_file_prepare failed
>>> [RPM] unpacking of archive failed on file /lib64/libgcc_s-14-20240912.so.1;674626bb: cpio: (error 0x2)
>>> Unpack error: libgcc-0:14.2.1-3.fc41.x86_64
[   1/1108] Upgrading glibc-common-0:2.40-12.fc41.x86_64                                                                                                                   100% |   1.0 GiB/s |   1.0 MiB |  00m00s
>>> [RPM] libgcc-14.2.1-3.fc41.x86_64: install failed
>>> [RPM] ima: could not apply signature on '/usr/bin/gencat;674626bb': Operation not permitted
>>> [RPM] Plugin ima: hook fsm_file_prepare failed
>>> [RPM] unpacking of archive failed on file /usr/bin/gencat;674626bb: cpio: (error 0x2)
>>> Unpack error: glibc-common-0:2.40-12.fc41.x86_64
[   1/1108] Upgrading glibc-gconv-extra-0:2.40-12.fc41.x86_64                                                                                                              100% | 207.7 MiB/s |   8.1 MiB |  00m00s
>>> [RPM] glibc-common-2.40-12.fc41.x86_64: install failed
>>> [RPM] ima: could not apply signature on '/usr/lib64/gconv/ANSI_X3.110.so;674626bb': Operation not permitted
>>> [RPM] Plugin ima: hook fsm_file_prepare failed
>>> [RPM] unpacking of archive failed on file /usr/lib64/gconv/ANSI_X3.110.so;674626bb: cpio: (error 0x2)
>>> Unpack error: glibc-gconv-extra-0:2.40-12.fc41.x86_64
[   1/1108] Upgrading glibc-0:2.40-12.fc41.x86_64                                                                                                                          100% |   1.1 GiB/s |   6.7 MiB |  00m00s
>>> [RPM] ima: could not apply signature on '/usr/lib64/audit/sotruss-lib.so;674626bb': Operation not permitted
>>> [RPM] Plugin ima: hook fsm_file_prepare failed
>>> [RPM] unpacking of archive failed on file /usr/lib64/audit/sotruss-lib.so;674626bb: cpio: (error 0x2)
>>> Unpack error: glibc-0:2.40-12.fc41.x86_64
[…]

This looks possibly similar to this bug which can apparently be worked around using the rpm flag --undefine=__transaction_ima but apparently there is no way to set that from dnf itself. Do you have any ideas on how I can complete the upgrade or how to unblock this?

P.S. I managed to upgrade DNF by copying the package download locations from dnf and running

sudo dnf install https://kojipkgs.fedoraproject.org//packages/dnf5/5.2.7.0/1.fc41/x86_64/dnf5-5.2.7.0-1.fc41.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dnf5/5.2.7.0/1.fc41/x86_64/libdnf5-5.2.7.0-1.fc41.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dnf5/5.2.7.0/1.fc41/x86_64/libdnf5-cli-5.2.7.0-1.fc41.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/fedora-repos/41/1/noarch/fedora-repos-41-1.noarch.rpm https://kojipkgs.fedoraproject.org//packages/librepo/1.18.1/1.fc41/x86_64/librepo-1.18.1-1.fc41.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/libsolv/0.7.30/1.fc41/x86_64/libsolv-0.7.30-1.fc41.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dnf5/5.2.7.0/1.fc41/x86_64/dnf5-plugins-5.2.7.0-1.fc41.x86_64.rpm

(since I noticed that anything from the official repos was failing, but I could upgrade packages from third party repos). I'm not sure why this only affects installing from the official fedora repos.