Red Hat Bugzilla – Bug 459910
Handling of source packages is a bit wonky
Last modified: 2009-06-03 04:47:55 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 ;-).
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?
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.
Unfortunately, the same mime-type is assigned for .src.rpm as .rpm, so unless we fix that we're always going to get launched.
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.
(In reply to comment #4)
> That way the root account is used as little as possible, which has to be a good
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'.
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.
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.
>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.
(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.