If I run `dnf install ...` as a user without sudo, dnf5 goes ahead but then fails because of permissions. Reproducible: Always Steps to Reproduce: $ dnf install somepkg Actual Results: : Repositories loaded. Package Arch Version Repository Size Installing: dnf-repo x86_64 0.5.4-1.fc39 copr:copr.fedor 32.7 MiB Transaction Summary: Installing: 1 packages Total size of inbound packages is 5 MiB. Need to download 5 MiB. After this operation 33 MiB will be used (install 33 MiB, remove 0 B). Is this ok [y/N]: y [1/1] dnf-repo-0:0.5.4-1.fc39.x86_64 100% | 1.9 MiB/s | 5.1 MiB | 00m03s -------------------------------------------------------------------------------- [1/1] Total 100% | 1.9 MiB/s | 5.1 MiB | 00m03s Verifying PGP signatures Running transaction Failed to open lock file "/run/dnf/rpmtransaction.lock": (13) - Permission denied Expected Results: dnf should refuse to attempt install if the instantiation does not have sufficient privilege. Is there an existing upstream ticket?
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
(In reply to Jens Petersen from comment #0) > Is this ok [y/N]: y > [1/1] dnf-repo-0:0.5.4-1.fc39.x86_64 100% | 1.9 MiB/s | 5.1 MiB | > 00m03s > ----------------------------------------------------------------------------- > --- > [1/1] Total 100% | 1.9 MiB/s | 5.1 MiB | > 00m03s > Verifying PGP signatures > > Running transaction > Failed to open lock file "/run/dnf/rpmtransaction.lock": (13) - Permission > denied > > Expected Results: > dnf should refuse to attempt install if the instantiation does not have > sufficient privilege. > Frankly, DNF5 does exactly what you described in Expected Results: It refuses to install if the user does not have sufficient privilege. It very clearly reports: Permission denied.
Would moving the privilege check between a confirmation question and a download operation fulfill your dream? Like this: Transaction Summary: Installing: 1 packages Total size of inbound packages is 5 MiB. Need to download 5 MiB. After this operation 33 MiB will be used (install 33 MiB, remove 0 B). Is this ok [y/N]: y Failed to open lock file "/run/dnf/rpmtransaction.lock": (13) - Permission denied
> Would moving the privilege check between a confirmation question and a download operation fulfill your dream? Like this: That'd be great. (In general, I think that the current behaviour is correct and desirable in most cases, i.e. to not do upfront permissions checks, but to instead let things run until a privileged operation happens naturally. This is better because it allows a more fine-grained permission error to be printed. It is also easier to implement correctly: the permission check is already implemented in the kernel, so the program doesn't need to do anything, except check the operation result, which it need to do anyway, because it may always fail. So simply never implementing the the upfront check leads to the optimal result. But there is an exception to this general rule: where the partial operation that happens before the permission error is costly. This is the case here: the user may wait hours for the download and/or may pay significantly for the bandwidth. Thus, I think that in this particular case, making sure that we have permissions will prevent such common operator mistakes and is a good idea.)
I have just added pull-request to fix this issue - https://github.com/rpm-software-management/dnf5/pull/1458 It would be nice if someone can review and help to improve it.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. 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 '39'. 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. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 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.
This was fixed by https://github.com/rpm-software-management/dnf5/pull/1505.
*** Bug 2181493 has been marked as a duplicate of this bug. ***