Bug 910133 - [plugin] checking permissions to perform rpm transaction before downloading
[plugin] checking permissions to perform rpm transaction before downloading
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: dnf-plugins-core (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ales Kozumplik
Fedora Extras Quality Assurance
: Reopened
: 973510 1038504 1044995 1053676 1066747 1069384 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-11 16:29 EST by Rahul Sundaram
Modified: 2014-09-30 19:41 EDT (History)
14 users (show)

See Also:
Fixed In Version: dnf-plugins-core-0.0.2-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-13 04:42:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Sundaram 2013-02-11 16:29:27 EST
Description of problem:

dnf install downloads packages first and then fails if it isn't run as root user and rerunning as root, re-downloads the packages all over again.  It should check first before downloading packages.
Comment 1 Ales Kozumplik 2013-02-12 04:51:35 EST
Note that RPM behaves the same way, it first downloads and then tries to perform the transaction:

[akozumpl@aklap ~]$ rpm -iv http://akozumpl.fedorapeople.org/t.new/mystery-devel-19.67-1.noarch.rpm
Retrieving http://akozumpl.fedorapeople.org/t.new/mystery-devel-19.67-1.noarch.rpm
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied)

Which makes a lot of sense because we can never now in advance whether the user is going to have the permissions to perform the transaction once we're finished downloading the packages and shouldn't assume he won't just because he doesn't at the moment when the downloads start.

Closing this as NOTABUG.
Comment 2 Rahul Sundaram 2013-02-12 12:46:08 EST
How is it possible for dnf to have permissions to install if it doesn't when dnf starts downloading?  Besides, RPM is typically dealing with one download at a time but dnf is typically dealing with multiple (the current RPM behavior of saying permission denied comes after a bug report by me fyi).  Besides, you are throwing away all the downloaded data and redownloading them all which is certainly a problem for users.
Comment 3 Ales Kozumplik 2013-02-13 02:51:24 EST
(In reply to comment #2)
> How is it possible for dnf to have permissions to install if it doesn't when
> dnf starts downloading? 

because the download doesn't happen as an atomic operation on the system, something can grant/revoke the rpm transaction privileges in the meantime. There's no point checking things in advance if they can change.

> Besides, you are throwing away all the downloaded data and redownloading
> them all which is certainly a problem for users.

But what else is there to do? The main dnf cache can not be writable by regular user, he could spoof package for installation into there.
Comment 4 Rahul Sundaram 2013-02-13 14:21:20 EST
I don't think in practice it does really change and checking in advance makes sense and that's what the expected behavior is as seen in other dependency resolvers including yum, apt etc.  I will just stop with voicing my objection to this decision.
Comment 5 Ales Kozumplik 2013-06-18 03:56:44 EDT
*** Bug 973510 has been marked as a duplicate of this bug. ***
Comment 6 Ankur Sinha (FranciscoD) 2013-10-20 08:23:07 EDT
Hi Ales,

I've seen a few users confused by this behaviour. If a certain operation cannot be carried out as a non root user, it's better to just stop the command right there. Downloading metadata makes them think that the command is running, and they're quite taken aback with the "don't have permissions" error later. Can you please reconsider this behaviour? 

Like Rahul's said, it may be possible that the permissions change, but I really doubt it's going to happen when using the dnf command line, or other frontends that may come up in the future. 

I see that this isn't required technically, but it's a usability issue here. 

Thanks,
Ankur
Comment 7 sirmy15 2013-10-20 08:33:15 EDT
Hi, it is really a weird behaviour, that confused me. And i think it is not right to download files if it can't install them. If i pay for my connection it consumes a lot of MB or GB for nothing.

Thanks
Comment 8 Ales Kozumplik 2013-10-20 13:22:10 EDT
Let me assure you again this is the standard behavior of many other linux apps: unless the app runs into a call that returns permissions etc. error it just keeps on executing whatever it set out to do. It's not a good idea to be trying to guess up front whether or not a particular operation will succeed, in many cases it is not even realistically possible (see comment 3). Besides, I personally know of many users who appreciate that DNF doesn't treat non-root users as special.

Closing this again. Once the plugin API is stabilized and the documentation published people will be able to write a simple plugin that does exactly what this bug is suggesting. For the time being I don't see anybody from the regular DNF contributors (planning to be) working on a plugin like that (speak up if you do).
Comment 9 Kevin Raymond 2013-10-30 09:53:25 EDT
I would really be disappointed if I start copying 300 TiB of data to an external hard drive, and I get the error "no more space" at 90%.
I have exactly the same feeling here. It starts processing, and them throw you away with this permission error.

It's not because other app works that way that it's the best way.

Either checking permission before and let the user getting privilege *now*, or getting the root privilege letter would be fine.
What prevent to log as root once dnf has found that you don't have root access?
Comment 10 Ales Kozumplik 2013-12-02 11:14:05 EST
reopening by popular demand. this will be provided as a plugin.
Comment 11 Ales Kozumplik 2013-12-05 08:14:11 EST
*** Bug 1038504 has been marked as a duplicate of this bug. ***
Comment 12 Ales Kozumplik 2013-12-19 07:18:20 EST
*** Bug 1044995 has been marked as a duplicate of this bug. ***
Comment 13 Ales Kozumplik 2014-01-13 04:42:57 EST
this is provided by the current dnf-plugins-core release, install it with:

$ dnf install dnf-plugins-core

and from then on, operations potentially trying to modify rpmdb will stop early.
Comment 14 Radek Holy 2014-01-15 11:37:27 EST
*** Bug 1053676 has been marked as a duplicate of this bug. ***
Comment 15 jpacner 2014-01-16 05:02:52 EST
Will this plugin be installed and enabled by default?
Comment 16 Ales Kozumplik 2014-02-19 02:44:38 EST
*** Bug 1066747 has been marked as a duplicate of this bug. ***
Comment 17 Ales Kozumplik 2014-02-25 01:17:13 EST
*** Bug 1069384 has been marked as a duplicate of this bug. ***
Comment 18 Ales Kozumplik 2014-02-25 01:43:22 EST
(In reply to jpacner from comment #15)
> Will this plugin be installed and enabled by default?

No, the user has to install dnf-plugins-core, then it's enabled.

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