Bug 459910 - Handling of source packages is a bit wonky
Handling of source packages is a bit wonky
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
9
All Linux
medium Severity low
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-24 06:57 EDT by Ed Avis
Modified: 2009-06-03 04:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-03 04:47:55 EDT
Type: ---
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 Ed Avis 2008-08-24 06:57:05 EDT
If you download a source RPM in Firefox, it has the same Content-type as a binary RPM so suggests using the package manager.  The package manager prompts for the root password and then gives an error that source packages cannot be installed.

It would be better for it to notice that this is a source package before prompting for the password.  You don't want to ask the user to enter the root password unnecessarily.

Perhaps it could prompt to save the source package to your SRPMS directory if you have one set in ~/.rpmmacros.

Automatically building and installing it would also be nice, but perhaps a bit ambitious for this bug report ;-).
Comment 1 Richard Hughes 2008-09-16 12:54:49 EDT
Well, we don't want to open the file until we know if it's a src.rpm or not. Should we just lift the restriction and offer to install the sources?
Comment 2 Ed Avis 2008-09-20 07:11:18 EDT
I think the main point is to do some basic checking on the package before prompting for the root password.  Typing in the root password is something the user should do as little as possible.  (Potentially, PackageKit could display the 'rpm -qip' style information and a PGP signature check before prompting for the root password.)

Installing the sources would be nice, or else just saving in the user's SRPMS directory.
Comment 3 Richard Hughes 2008-10-27 09:23:50 EDT
Unfortunately, the same mime-type is assigned for .src.rpm as .rpm, so unless we fix that we're always going to get launched.
Comment 4 Ed Avis 2008-10-28 09:44:25 EDT
Yes, the same handler program always gets launched, but it should do some checking of the package before prompting for the root password.  If the package is a source package, it can offer to save it to disk.  If a binary package, it can check the architecture is appropriate, dependencies are installed, signature is okay, and *then* prompt for the root password, become root and run the normal install process (which may duplicate some of these checks, but that's fine).

That way the root account is used as little as possible, which has to be a good thing.  It doesn't make sense to first become root and then give an error that the package can't be installed, when that error condition could just as easily be tested by an unprivileged process.
Comment 5 Richard Hughes 2008-10-28 12:16:38 EDT
(In reply to comment #4)
> That way the root account is used as little as possible, which has to be a good
> thing.

I totally agree with you, no argument, but the way PackageKit works is by processing the mime type, not the file extension -- and the mime type is the same for both sorts of files.

We can't just check for suffix(.src.rpm) as that's encoding logic in a frontend that is distro neutral. The best fix here is to give .src.rpm's a different mime type to binary rpm'.
Comment 6 Ed Avis 2008-10-28 13:06:26 EDT
But source RPMs can be distinguished from binary ones by their content - it is not necessary to rely on MIME type.  Similarly, a binary RPM for i386 has the same MIME type as a binary RPM for m68k, but that doesn't mean that PackageKit cannot distinguish between the two, and do so *before* asking for the root password.
Comment 7 Richard Hughes 2008-10-30 06:41:59 EDT
PackageKit doesn't decompress the rpm -- it just passes a public filename to yum and asks yum to do the install with dependencies. PackageKit just checks the file exists, and then passes it one layer down. To ask yum to inspect the file requires root privs (as the rpm could contain overflows or exploit code, and is not GPG signed) -- so we have to do this as an authorised context.
Comment 8 Ed Avis 2008-10-30 10:24:45 EDT
>To ask yum to inspect the file requires root privs (as the rpm could contain
>overflows or exploit code, and is not GPG signed)

Surely that is an argument for _not_ doing the inspection as root?

Because the file could contain buffer overflows that might exploit bugs in yum or the rpm libraries, it is dangerous to first become root and then examine the file.  Much safer to first perform sanity checks on the file as an unprivileged user, and only become root when it's needed.
Comment 9 Richard Hughes 2009-06-03 04:47:55 EDT
(In reply to comment #8)
> Because the file could contain buffer overflows that might exploit bugs in yum
> or the rpm libraries, it is dangerous to first become root and then examine the
> file.  Much safer to first perform sanity checks on the file as an unprivileged
> user, and only become root when it's needed.  

The client code is distro agnostic, and doesn't know the difference between .rpm and .deb. If a src.rpm and a rpm both have the content type application/x-rpm then there's not a lot we can do, sorry.

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