[packagekit] libpackagekit-gnome

[Richard Hughes]

On Sun, 2008-04-13 at 16:55 -0400, David Zeuthen wrote:
> 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.

That's exactly why I didn't proxy the requests, I wanted per-app auth.
This might be insane, I'm not sure yet.

> 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

Well, it all boils down to if per-app auth is a hindrance, or a
blessing.

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

That's basically what I wanted libpackagekit-gnome to look like - very
high level.

> 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.

Hmm, valid point.

> 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).

Why would we have to lock down totem? - by lock down do you mean get an
auth to install a file?

Richard.