My 2 pence on this is that from a clean slate we should have 2 interfaces for cups:
cupswhich allows an application to talk to the cups daemon over DBus, access the CUPS socket, etc.
cups-supportwhich provides the accesses necessary to operate as the cups daemon
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.
cups-control interface would be plugged by only the confined
ipp-service-cups snap, much like
lxd-support is only plugged by the official
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
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?
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 https://github.com/snapcore/snapd/pull/7417 for example.
Does this just mean a network port? Is there a reason why the
network interface is insufficient for this specific access?
This should be fine to add to the interfaces.
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
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.