Can apps start dbus activated apps inside the same flatpak container?

[Alexander Larsson]

Evolution has a similar problem, where it depends on the
evolution-data-server dbus service. I believe what the evolution does
is that they ship a copy of it, renamed to be part of the app, and
then first try the system-wide name, and if that doesn't exist it
starts the one scoped to the app.

You can see where it builds the custom copy of e-d-s here:
 https://github.com/flathub/org.gnome.Evolution/blob/master/org.gnome.Evolution.json#L247

Now, you say the service is part of the runtime, but that means the
binary is accessible by the app, so all it needs to do is to make a
copy of the runtime service file and rename it to the app-id.

There is another approach. You can give the app permissions to own the
real name itself with `--own-name=org.kde.kssld5`. However, this is
risky, as it may conflict with the system copy, or one from another
flatpak app, and their exact versions may differ.

You could possibly  use a uniquified copy of the service name, like
`org.kde.Platform515.kssld5` and have each app be allowed to own that,
then all the kde apps with the same runtime will share the same copy
of the service at least, although it may cause the copy from some
other app to be launched.

On Wed, Oct 20, 2021 at 10:23 PM Albert Astals Cid <aacid at kde.org> wrote:
>
> El dimecres, 20 d’octubre de 2021, a les 0:12:53 (CEST), Bastien Nocera va escriure:
> > On Tue, 2021-10-19 at 23:20 +0200, Albert Astals Cid wrote:
> > > When finding a "unsafe SSL certificate" applications using the KDE
> > > Frameworks libraries ask the org.kde.kssld5 dbus service what to do
> > > with it since the user may have encountered that certificate first and
> > > already said "yes i don't care" or "take me away from here fast".
> > >
> > > Now the problem we have in flatpak is that we can't assume that
> > > "outside" system will know about org.kde.kssld5 because the user may be
> > > running a system that knows nothing about it.
> > >
> > > We actually do package the binary and dbus autostart files in the KDE
> > > flatpak runtime so if the runtime could start that service, it would
> > > all work out.
> > >
> > > But we have no idea if flatpak can be configured to do that.
> > >
> > > Is there any way to say "sure autostart this dbus service inside the
> > > container, it's fine" in the flatpak world?
> >
> > Yes you can, but the service's prefix needs to match the name of the
> > application.
>
> Sadly that doesn't work for us since the dbus service is part of the runtime, not of the app itself.
>
> Any other option?
>
> Best Regards,
>   Albert
>
>
>
> > This is, for example, how totem and rhythmbox have their
> > own dleyna UPnP/DLNA D-Bus services:
> > https://github.com/phako/dleyna-server/commit/fe3caa88097def0eab675aff8a437ad10a0bab7f
> > https://github.com/flathub/org.gnome.Totem/blob/master/dleyna/dleyna-server.json
> >
>
>
>
>


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com