Interface request: "cups-control" on CUPS snap and including D-Bus

[ijohnson]

My 2 pence on this is that from a clean slate we should have 2 interfaces for cups:

• cups which allows an application to talk to the cups daemon over DBus, access the CUPS socket, etc.
• cups-support which provides the accesses necessary to operate as the cups daemon

The cups interface would be plugged by an application like LibreOffice that wishes to print. It would either connect to a slot provided by the core/system snap if and only if there is not an “official” cups snap, but if there is an “official” cups snap installed, the slot comes from that snap instead (this distinction is useful because we can have different accesses depending on if the snap is connecting to an unconfined cups daemon, or if it is connecting to a confined cups daemon that is packaged as a snap.

The cups-control interface would be plugged by only the confined ipp-service-cups snap, much like lxd-support is only plugged by the official lxd snap.

The only caveat I will add to this is that I seem to remember @jdstrand mentioning some time that the cups-control interface has some specific accesses that make it unsafe or unreasonably powerful and that we couldn’t properly mediate it, so some apps have been denied auto-connect for the cups-control interface. This might complicate my proposal above, meaning that we can’t have cups and instead need to have cups-control and all its unreasonably wide accesses for applications wanting to print using the official ipp-service-cups snap.

@till.kamppeter

• A snapped application has a plug to the “cups-control” interface. This leads to a CUPS installed from Debian packages into the base system

I don’t quite follow this, are you saying that installing a snap application that plugs cups-control triggers debian packages to be installed on the system?

@till.kamppeter

• There needs to by some kind of automatic switch for which CUPS is actually installed.

I don’t know that this work is completely done, but there is work around a “greedy” snap declaration which allows a snap application to declare that it should connect to “all such slots”, but I think this could perhaps be extended to have some logic like connecting to “the system slot if it exists, or a specific slotting snap if that snap is installed”. See Plug/slot declaration rules: greedy plugs for the current state of things. There has been prior requests for this kind of behavior at least at interfaces/wayland: on classic systems only consider the OS slot for auto-connect by AlanGriffiths · Pull Request #7417 · canonical/snapd · GitHub for example.

@till.kamppeter

also IP access via localhost:631

Does this just mean a network port? Is there a reason why the network interface is insufficient for this specific access?

@till.kamppeter

also D-Bus services (AFAIK /org/cups/cupsd/Notifier and /com/redhat/PrinterSpooler at least)

This should be fine to add to the interfaces.

@till.kamppeter

The “dbus” snap interface is not very well suited for CUPS as a client snap would need to connect to “cups-control” and two “dbus” interfaces, so 3 interfaces would need to get connected, therefore I like to have that all in one “cups-control” interface.

Rather than have apps plug cups-control and 2 dbus interfaces, we should probably just add the dbus rules to the cups interface I mentioned above, then applications only need to plug cups.

@till.kamppeter

Note that the CUPS snap will soon get renamed, from the current “printing-stack-snap” to “ipp-service-cups”.

AFAIK, the store does not support renames, is there a significant user base here of the printing-stack-snap? If so you will probably want to put together a migration plan to get users to manually install the ipp-service-cups snap instead.