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

snapd
9

The summary of our meeting is as follows:

  1. we want to be able to support 3 different user experiences:

    1. snap consumers already plugging cups-control to continue to be able to print to cups via distro packaging
    2. snap consumers already plugging cups-control to be able to print to cups packaged as a snap
    3. non-snap consumers to be able to print to cups packaged as a snap

    Due to the above, the snap providing cups will bind to /run/cups.sock (where /var/run is a symlink to /run) and listen on the standard 631 network port. The snap providing cups may at its discretion implement a fallback mechanism for testing purposes that puts its unix socket in SNAP_DATA/SNAP_COMMON (optionally exporting via the content interface) and listen on 10631 (or wherever)

  2. the cups-control interface will continue to support implicitClassic for 1.1, above

  3. the cups-control interface will be modified to also support ‘slot-snap-type: app’ to support 1.2, above

  4. rather than implementing an additional interface for cupsd accesses, the snap providing cups will ‘slots: cups-control’ which will grant via PermanentSlot any cupsd-specific accesses. The snap providing cups will plugs existing interfaces like ‘network’, ‘network-bind’, ‘avahi-control’, etc as needed

  5. per @till.kamppeter, the DBus interface is only about monitoring and subscribing to notifications, not about administration and these will not change. For now (though this is subject to change in PR review), we will add the appropriate DBus accesses to cups-control (esp for cupsd to bind to the interfaces and respond to requests from unconfined processes; adding the accesses for plugging snaps to use is likely also fine since they can get this information from the admin portions of the socket APIs). This helps support 1.3, above

In addition to the above, we discussed what it would take to allow auto-connection for printing. Note that printing is only done through the socket (not the DBus APIs). Also, recall that cupsd’s decision on whether to allow admin functionality to the connecting user is based on group membership. With typical desktop applications on single-user installs, the uid of the process the snap is running as will already be in this group, which means that connected snaps will typically have the necessary group membership to configure printing on the system rather than just print (which is why it is named ‘cups-control’ instead of ‘printing’ or similar). To address this, we discussed that a patch could be developed similar to what was done for pulseaudio, where cupsd would:

  • look at the PEERCRED of the connecting client process to obtain the pid/etc of the process
  • in addition to cupsd’s normal group checks, it would ask snapd (eg, via snapd-glib or similar) to see if the connecting process is from a snap
  • make a decision based on this information. An initial implementation might simply deny access to admin functionality if the connecting process is a snap. A future implementation might have cupsd then ask if a specific interface is connected, and if so, allow the admin access (a suggestion would be to introduce a new ‘cups’ interface that allows access to the socket and only if cups-control is connected would admin access be allowed).

This patch should be upstreamed to Apple. @till.kamppeter said he would discuss patching cupsd with @jamesh and see if a PoC could be developed in time for an upcoming OpenPrinting summit. If they are amenable to the change, we can consider changes to snapd. In the meantime, distros could choose to distro-patch as desired.

@till.kamppeter - as a future improvement to the snap, I suggested perhaps looking into using the ‘snap_daemon’ user instead of running as root. See System usernames for details and caveats.

1 Like