Privileged helper for xdg-app

[Emmanuele Bassi]

Hi;

On 8 January 2016 at 14:20, Alexander Larsson <alexl at redhat.com> wrote:
> On fre, 2016-01-08 at 13:46 +0000, Emmanuele Bassi wrote:
>> 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
>
> I'd go even further. I don't want the root-privileged daemon doing
> network i/o at all. So, I think we want to support:
>
>  * install (update if already installed) ref from local repo
>  * remove ref
>
> Then, to use this the "client" would make a shallow clone of the local
> xdg-app repo (by using the parent_repo feature of ostree) and then
> doing the network i/o. When that is done it would call the dbus api to
> trigger the import.

Sounds good. Our app manager daemon used to do the networking side of
things, but I removed it, and it picks up the bundles from a know
location on the disk, where the user-facing app store put them.

>> We have a default policy that allows "admin" users to install without
>> a password, and that has worked fairly well for us.
>
> What does that mean? Wheel group membership?

We do two checks: one to check if the user is on the "wheel-like"
group, and the other via polkit. I added that because I wanted to have
a small command line utility that used the internal implementation
without going through DBus, if launched with the right Unix
permissions.

>> 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.
>
> With my proposal above (downloads happen outside the daemon) I don't
> really think it makes sense to cancel operations at all. While they are
> not instant, they are at most the order of ten seconds.

Sure; in our case installation operations can take a bit longer (we
still target spinning rust drives and we do a bunch of work to ensure
that we can roll back on error, as well as calling local
post-installation hooks).

>> >
>> > * do we support adding and removing remotes system-wide as well, if
>> > so, policy?
>
> This one is more tricky, as adding a trusted remote hands over new
> permissions to other users... I'd say lets avoid it for now and require
> root/distro/initial-setup to set up things.

I agree. We can add a simple configuration tool later.

Ciao,
 Emmanuele.

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