Privileged helper for xdg-app

[Emmanuele Bassi]

Hi all;

Here's the small helper we use in Endless; ideally we can modify it for
future use in xdg-app.

https://github.com/endlessm/eos-app-manager

Ciao,
 Emmanuele.


On Friday, 8 January 2016, Emmanuele Bassi <ebassi at gmail.com> wrote:

> Hi;
>
> On 8 January 2016 at 13:26, Richard Hughes <hughsient at gmail.com
> <javascript:;>> 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]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20160109/1616e686/attachment.html>