Privileged helper for xdg-app

[Emmanuele Bassi]

Hi;

On 8 January 2016 at 13:26, Richard Hughes <hughsient at gmail.com> wrote:
> Hi all,
>
> For gnome-software we need to do all actions with user permissions.
> We'd then need a privileged helper to install applications
> system-wide. Several thoughts come to mind:
>
> 1. Just reuse PackageKit: I think this is using a steamroller to crack
> a nut, and also ties us to a lot of the traditional problems, and
> would also need us to support mixed-backend functionality
> 2. Just use a pkexec binary: I think this would work, but doesn't give
> us any of the progress information we need for a GUI client (i.e. is
> fire-and-forget)
> 3. Create a small daemon (possibly living in xdg-app git) which just
> auto-launches, claims a bus name systemwide, does the operation and
> then quits.

At Endless we have a daemon like this. It used to be way too clever,
until we dropped 99% of it and made it fairly dumb.

The only things it does are:

 * sit on the system bus via auto-activation
 * use polkit to do privilege escalation
 * install
 * update
 * remove

There are added things, like running scripts and managing our own
bundles - but the idea is to move it to use the xdg-app API as well
while we transition to xdg-app.

Currently the daemon is not open, but we've been meaning to make it
public it up for a while, given its reduced scope. I'll try and see if
I can get it done ASAP.

> Option 3 makes most sense in my head, but does need the usual GDBus
> overhead, XML interface files, dbus permission file, etc. We'd also
> have to decide some key things like:
>
> * default policy of who can do what: PK makes this even harder by
> allowing "signed" applications to be installed without the admin
> password

We have a default policy that allows "admin" users to install without
a password, and that has worked fairly well for us.

> * do we support more than one operation to be done in parallel: making
> things simple means we have to just have a percentage property without
> worrying about "transactions" and things happening in threads

We really, really do want operations to run in parallel as much as
possible. Users already try to install/update/remove multiple apps.
One of the reasons for the simplification of our privileged installer
daemon was that it made parallel operations really easy to handle.

You need a transaction object on the bus, sure; but you don't need
weird queues, since the object will be kept alive until the operation
is either terminated or cancelled.

> * what should we log, and where?

We use the systemd journal, but we can also log out to stderr when debugging.

> * do we support adding and removing remotes system-wide as well, if so, policy?
> * who can cancel operations: just the current user/should operations
> be cancelled if the session also goes away?

We already cancel any pending transaction if the sender goes away,
which is fairly simple to do.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]