Handling of the "cups" plug by snapd, especially auto-connection

snapd
22

I have the following remarks:

  1. For sole printing and displaying print dialogs which list the available print queues and show the user-settable options for each print queue one only needs the domain socket of CUPS and if it is not at the standard location /run/cups/cups.sock we need to set the CUPS_SERVER environment variable to the actual location (the CUPS Snap is ALWAYS listening on /var/snap/cups/common/run/cups.sock and it is ALWAYS mediating).
  2. D-Bus notifications are an optional service of CUPS. If a client subscribes, CUPS gives push notifications via D-Bus about changes on printer status, available queues, configuration changes, job status, … They are not needed for printing and for displaying standard print dialogs, not used by most client applications which print. They improve possibilities though, as with them a print dialog could update on changes in real time and it could also give the user a way to track their jobs in real time.
  3. The cups-control interface is a complete interface for CUPS clients, it contains both access to the CUPS domain socket plus access to the D-Bus notification facility (and perhaps other features, so let us say cups-control allows access to the CUPS domain socket and the “CUPS extras”).
  4. We need to force snapped applications print through the snapped CUPS as the snapped CUPS always has Snap mediation, the system’s CUPS only in rare cases (and we cannot check this from the outside). To have assure that snapped applications and unsnapped applications see the same printers if we are on a system with unsnapped CUPS, we need to force-install the CUPS Snap in proxy mode.
  5. The interface of CUPS is rather complex, so writing a new “mediation shell daemon” which looks/behaves like CUPS for snapped applications and passes on non-admin requests to the system’s CUPS is way more complex and bug-prone than simply using the actual CUPS (the one in the CUPS Snap) as this “mediation shell daemon”.
  6. @jamesh came with an approach on Mattermost to use the xdg-desktop-portal which flatpak uses. This is more or less like the “Common Print Dialog” which I tried to establish back in 2006 together with some GUI experts but did not succeed due to lack of available coding workforce. The applications do not have their own print dialog but call functions via D-Bus to pop up a print dialog and to actually print. This would probably solve all the problems of the print dialogs I am complaining about, but this is not viable here as all applications would need highly invasive modifications for snapping them, an d snapping command line apps for headless servers will get impossible.
  7. So there seems to be no way to protect an existing CUPS on an arbitrary distribution against admin requests by simple AppArmor and other Snap-typical sandboxing techniques. The proxy CUPS seems to be the easiest-to-implement way.

So our print interface needs:

  1. Printing from Snaps forced through the CUPS of the CUPS Snap so that this CUPS mediates
  2. If the main system’s CUPS is some CUPS installed with the distribution (it is usually not mediating) the CUPS of the CUPS Snap works as proxy. This proxy mode is already implemented.
  3. If there is no CUPS from the distro, the CUPS of the CUPS Snap goes into stand-alone mode to work as the main CUPS. In this case the snapped CUPS also listens on /run/cups/cups.sock so that unsnapped apps can also print (this is also already implemented in the CUPS Snap).
  4. We can simply make the print interface let the CUPS_SERVER env variable be set to /var/snap/cups/common/run/cups.sockso that the snapped app prints to the snapped CUPS and in addition not allow the snapped app access /run/cups/cups.sock to protect against apps which override the env variable and switch (or hard-code) to /run/cups/cups.sock internally.
  5. Better than (4) is that if the print interface bind mounts /var/snap/cups/common/run/cups.sock to /run/cups/cups.sock in the application Snaps instead of setting the CUPS_SERVER env variable, as them badly (or maliciously) programmed apps hard-coding to /run/cups/cups.sock can also print, but only print, not administrate as the job goes through the CUPS of the CUPS Snap.
  6. Whatever the print interface does, it has also to support all the “CUPS extras” which I mentioned in (3) in the beginning of this posting.
  7. The cups-control interface should NEVER route requests through a proxy CUPS, as administrative requests through the proxy CUPS are technically not possible. It should always directly talk to the main CUPS which actually executes the jobs. So it should not do any bind mounting and ALWAYS talk to /run/cups/cups.sock. Then in distros with their own classic CUPS it talk’s to the distro’s CUPS and on systems with the CUPS Snap as main CUPS (stand-alone mode) it talks to the snapped CUPS.
  8. Both the print interface and the cups-control interface should support the very same “CUPS extras” in addition, the ones of the current cups-control interface.

I hope such a set of interfaces could be implemented, especially with (5) instead of (4). Please tell me what I should do from my side for that. Thanks.