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

snapd
43

The issue I saw with using /run/cups/cups.sock as the bind mount destination for the cups socket originating from the cups snap is that it excludes using cups-control at the same time with the real socket at that location - this means that in order to give a snap using the cups interface additional admin privileges, you would have to disconnect the cups interface, whereas if the socket from cups that does proxying is bind mounted elsewhere, then you can have both sockets accessible at the same time.

I suppose maybe this is a disadvantage though, since client apps probably won’t have an easy way to switch which socket location they use, and at least with bind mounting the proxying socket in the same location, snap apps don’t need to change where they look for the socket if they want to switch between using the cups and the cups-control interface, and the way to switch is just disconnecting cups and connecting cups-control. In the case where cupsd on the host is actually coming from the cups snap, then client snaps don’t need to disconnect cups, as the cupsd from the cups snap will be able to identify that the client end of the socket has the cups-control interface connected.

I think I’ve been convinced and instead what we should do is a simpler version of above:

  1. The cups snap shall still slot the cups interface for client apps wishing to print to plug
  2. The cups snap shall provide a basically empty cups-auto-connect-hack (name TBD) content interface that client snaps wishing to print can plug (but note that client snaps wishing to print do not need to plug this - this content interface exists purely so we can get default-provider working so that the cups snap is auto-installed everywhere properly) (eventually this content interface can go away when we support default-provider for the cups interface)
  3. Client snaps can plug cups and they will get auto-connected to the slot exposed by the cups snap
  4. Client snaps can also plug the cups-auto-connect-hack content interface with the default-provider set to cups, such that when a user installs this snap (and they do not yet have the cups snap installed), then the cups snap will get automatically installed if it is not already installed.
  5. The cups slot shall gain a new attribute (call it cups-socket real name TBD) that the cups snap can use to specify the location the unix socket that cupsd listens on that can be bind mounted by snapd into the mount namespace of the client snap that has a cups interface plug connected. This would be implemented with the mount backend internally in snapd interface code.
  6. The cups interface on the slot side shall perform a bind mount of the cupsd unix socket identified by the slot side cups-socket attribute to the standard location of the cups socket /run/cups/cups.sock
  7. Snaps wishing to do more than just submit print jobs and wishing to actually administrate and control printers etc, shall plug the cups-control slot, which can either be manually connected to the system, implicit slot or to the slot provided by the cups snap. This interface would allow accessing the standard cups socket location /run/cups/cups.sock (regardless of whether that socket location is a bind mount from the cups interface or not) so that snaps could talk directly to cupsd, whether that be the version in the snap, or a version installed on the host system through debs/rpms/etc.
  8. The cups snap specifically shall operate in one of two modes, it shall either be a proxy, and just listen on the /var/snap/cups/common/cups.socket socket (which is the source for the bind mount explained above and is the actual socket file that client snaps talk to) or it shall be the “real” cupsd and expose itself to unconfined apps on the host by listening also on /run/cups/cups.sock for traditional non-snap apps to print to directly. This means that app snaps using cups-control and wishing to do printer administration may end up talking to cupsd from the cups snap in the special case where the only cupsd on the system is that of the snap.

This means we just need the following change in snapd:

  1. the cups interface shall implement a bind mount from the location identified on the slot side of the interface to /run/cups/cups.socket inside the plug side snap’s mount namespace

And then the cups snap would need the following changes:

  1. expose the content interface slot that client snaps can use with default-provider as described above
  2. change the cups slot declaration to specify the attribute cups-socket: $SNAP_COMMON/cups.socket or some such

and client snaps need no changes except to add the content interface plug definition with default-provider: cups for the best install experience.

1 Like