Snapping CUPS Printing Stack: Avahi support, system users/groups

[jdstrand]

@till.kamppeter

1. Avahi (DNS-SD) supoort To be able to print on printers in the local network one needs to discover them and the current, universally accepted standard for that is DNS-SD. The implementation of DNS-SD on Linux and many other free software operating systems is Avahi. Our printing stack uses Avahi in two directions: As a client, where our printing stack browses Avahi recorrds of remote servers to find printers to print on and as a server, so that our printing stack can share local printers. Are there already interfaces for a snap to do that? If so, please post links to documentation and examples on how to use them. If not, pleae tell me how to do a feature request. What does the interface “avahi-observe” do and how do I use it?

From: https://github.com/snapcore/snapd/wiki/Interfaces “Can browse for mDNS/DNS-SD services on the network via Avahi.”

This isn’t enough for what you’d need, however, there is a PR in review that you might be interested in: https://github.com/snapcore/snapd/pull/3624

@till.kamppeter

2. Non privileged system users/groups CUPS uses some system users and groups for its internal workings. Most important is the “lp” user. CUPS runs filters (external utilities to convert file formats for printing) and most backends (external utilities to communicate with printer hardware) as the unprivileged user “lp” (whereas the CUPS daemon itself runs as root) for security reasons. “lp” is member of the group “lp” so that one can make printer device files group-writable for the “lp” group. There is also the “lpadmin” groups. Not only root can do CUPS administration (creating/modifying/removing print queues, manipulating any user’s jobs) but also all the users of the “lpadmin” group. The names are not hard-coded in CUPS. They can be modified (for example if it is easier to implement with names starting with “snap_…”). Here I would like how to do this in snaps. I have seen a recent thread here discussing this, but it seemed only discussion of ideas. Is there already implemented something?

Not yet, but the design is almost there: Multiple users and groups in snaps

I can say that part of implementing this design will be doing seccomp policy to allow using uids and gids, and the first uid/gid that will be allowed is the system ‘daemon’ user/group which is not dependent on the rest of the design (in fact, the only reason why it isn’t implemented yet is because of the various issues with rolling out new seccomp policy that are finally addressed in snapd 2.26.14).

@till.kamppeter

There is a “cups-control” interface which looks like that snaps using it can do the tasks which members of the “lpadmin” group can do (but with a classically installed CUPS). Am I right? How does this interface work? I would like to have this interface acting on the CUPS snap.

This interface (currently) allows nothing more than the cups-client apparmor abstraction (ie, connecting to the cups socket) and group membership is not mediated by snapd but instead enforced by the cupsd daemon. It is only available on classic. To be available on core, you’d have to extend the cups-control interface in a similar manner as the aforementioned PR for avahi to allow a slot implementation snap to run as cupsd and allow connections to it.