Hi all;<div> </div><div>Here's the small helper we use in Endless; ideally we can modify it for future use in xdg-app.</div><div> </div><div><a href="https://github.com/endlessm/eos-app-manager">https://github.com/endlessm/eos-app-manager</a> </div><div> </div><div>Ciao,</div><div> Emmanuele.</div><div> On Friday, 8 January 2016, Emmanuele Bassi <<a href="mailto:ebassi@gmail.com">ebassi@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi; On 8 January 2016 at 13:26, Richard Hughes <<a href="javascript:;" onclick="_e(event, 'cvml', 'hughsient@gmail.com')">hughsient@gmail.com</a>> 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. -- <a href="https://www.bassi.io" target="_blank">https://www.bassi.io</a> [@] ebassi [@<a href="http://gmail.com" target="_blank">gmail.com</a>] </blockquote></div> -- <a href="https://www.bassi.io" target="_blank">https://www.bassi.io</a> [@] ebassi [@<a href="http://gmail.com" target="_blank">gmail.com</a>]