OpenPrinting distribution in OCI containers

[Jonas Ådahl]

On Thu, May 05, 2022 at 12:38:40PM -0700, Christian Hergert wrote:
> On 5/4/22 3:25 PM, Andrew Hayzen wrote:
> > It looks interesting in that it can run an image with some sandboxing
> > and appears like a normal systemd service.
> 
> I've wanted something similar for Sysprof so that we could distribute it as
> a Flatpak (and have sysprofd installed on demand w/ portable service).
> 
> The things currently limiting in that regard that we'd need to overcome to
> make it work well:
> 
>  * Make sure we can install the portable service using the D-Bus interface,
> passing an FD for the squashfs/tar/etc for deployment.
>  * Teach systemd to hold a reservation on a D-Bus name that will be taken by
> the portable service.
>  * Teach the portable services to be spawned with a SOCKET_FD or similar
> which already owns the D-Bus service name and take over that connection for
> the bus connection.
>  * Most likely if we're using D-Bus for communicating with privileged
> services we also need policy kit integration at the portable service level.
> That means polkit needs to allow dynamically registered policy which is
> revoked/unloaded when the portable service exits or is purged.

To add to the list of use cases where a third party system service is
hard to distribute and integrate with is graphical remote login
services.

A remote login service has a few special needs that needs special care,
apart from all the other details others have mentioned. It needs to be
able to

  * launch new login sessions,
  * take over existing login sessions,
  * spawn sandboxed user services with certain elevated privileges in
    either newly started or existing user login sessions,
  * access privacy sensitive APIs without being able to rely on typical
    portal behavior,
  * be autostarted on boot.

Some of these can be achieved with some kind of policy kit integration
for providing access to privileged APIs (e.g. logind), while for other
parts the APIs simply doesn't exist for non-portal use cases yet.

For portal-like APIs that cannot be handled like most portals due to
lack of ability to rely on user consent and interaction, a consensus
needs to be reached whether portal APIs should, when needed, be extended
to handle system services like needs, or whether complete separate
non-portal APIs for similar use cases needs to be developed.

See for example https://github.com/flatpak/xdg-desktop-portal/issues/759
for a request about this.


Jonas