[packagekit] libpackagekit-gnome

[David Zeuthen]

On Fri, 2008-04-11 at 20:49 +0100, Richard Hughes wrote:
> I've created a libpackagekit-gnome library in master, in the
> gnome-packagekit tree. This will allow GNOME applications to do trivial
> package installs, and not have to worry about status package_id's, gpg
> keys and all that fuzz. It also means we can use gnome-keyring and gconf
> and all that jazz.
> 
> So basically, if you want to install software in GNOME, you'll want to
> use libpackagekit-gnome, not libpackagekit.

This sounds useful. Is the application using the library (e.g. Totem)
going to call directly into the PackageKit daemon (and, via an PolicyKit
authorization agent, ask for it's own authorizations) via the library or
are you going to proxy library usage through a D-Bus session service?

Keep in mind that authorizations obtained through authentication are now
constrained to the exe-name and SELinux security context. If even if
you've already authenticated for org.freedesktop.packagekit.install
from, say, /usr/bin/gpk-application, then that authorization doesn't
work from, say, /usr/bin/totem.

(This is in fact pretty intentional. We don't really want any random
program to be able to ask the PackageKit daemon to install a package
just because you've once allowed the program /usr/bin/gpk-application to
do this. Of course, until we get a secure windowing server (e.g. X), a
secure toolkit (e.g. gtk) and lock down the PackageKit UI tools this
doesn't add any real security. [1])

So perhaps it would be useful to channel all this through a proxy in the
session that asks for the users consent, helps find the packages and so
forth. For example

 The application Totem is wants to install plug-ins to display
 media of the format XYZ.

                                        [Cancel] [Search for packages]

where [Search for packages] brings you onto another screen where the
found packages are shown (if any) and generally helps the user achieve
finding packages (e.g. short cut to add repositories, whatever).

So maybe what you really want isn't a library. Maybe what you want is
just a simple D-Bus interface on the session with a few methods for what
to install. For example

 InstallPackages (String package_names[])
 InstallGStreamerCodecs (String codecs[])
 InstallXineCodecs (String codecs[])
 InstallLinuxDeviceDriver (String modalias_list[])

Which is a lot higher-level and requires much less integration with each
application. And for bonus both gnome-packagekit and (some future)
kde-packagekit can provide that D-Bus interface. Meaning that users get
native looking KDE packagekit dialogs even when using Totem under KDE.

The main bonus, from a security point of view, here is that we only have
to securely lock down the program providing this hypothetical D-Bus
service to avoid rogue software in the session to abuse e.g. an
authorization for .install that is valid for /usr/bin/totem (Totem would
be a lot of work to securely lock down, not to mention it would be
pointless).

I think a D-Bus service is a lot nicer than library and I hope this mail
explains why.

      David

[1] : See

http://hal.freedesktop.org/docs/PolicyKit/polkit-polkit-sysdeps.html#polkit-sysdeps-get-exe-for-pid

for the longer story.