This is to discuss what needs to get added to snapd to make it safe to auto-connect the
cups plug of applications which print, the original discussion is not very visible, hidden in this PR
to get the best possible user experience with printing in the world of Snaps we have introduced a new interface named
cups. If you snap an application which has print functionality (like LibreOffice, photo editors/managers, …) you should simply plug
cups and with this the application is allowed to print, but not to manage CUPS (create queues, delete anyone’s jobs, …) and this interface should auto-connect when installing the application Snap. This way application developers can easily upload applications with printing functionality to the Snap Store and users can easily install, them, use them, and print their work, and that all without compromising the security of the printing service on the user’s system.
cups is different from
cups-control. The latter interface allows full control of the system’s CUPS, including managing CUPS. Therefore
cups-control should not auto-connect. See also my example Snaps to demonstrate the differences.
If one thinks that in a snappy world the available CUPS simply comes from the CUPS Snap which has Snap mediation, meaning that its cupsd checks for all administrative client inquiries (asking for creating/modifying queues, deleting anyone’s jobs, …) whether if they come from a fully confined Snap that the Snap actually plugs
cups-control and not only
cups before accepting them, one could easily let
But unfortunately, not every system which allows installing Snaps from the Snap Store (every system which has snapd installed) provides its printing services by the CUPS Snap (we cannot do that right now, as we need to test the CUPS Snap and we need to convert all printer drivers to Printer Applications as the CUPS Snap does not support classic printer drivers), most run classically installed CUPS, without Snap mediation. I have added the Snap mediation to CUPS upstream, but this support only come with the next release, not every distribution will make use of it as then CUPS would need libsnapd-glib, and there are many installed systems out there without it.
This means most systems run classically installed CUPS without Snap mediation and there a Snap plugging
cups has full admin access to the classically installed CUPS. See the discussion which started in the Pull Request to make
cups implicit in snapd.
Therefore one cannot generally say “auto-connect the
cups plug when installing a Snap using it” but one would rather have to say “auto-connect the
cups plug when installing a Snap using it if the CUPS Snap is present”, and one even had to change the
snapcraft-runner script (the one wrapping all apps of a Snap to set things like
PATH, …) adding something like this at the end:
[...] if which cups.lpstat > /dev/null; then export CUPS_SERVER=`cups.lpstat -H` fi exec "$@"
to assure that any libcups function used accesses the snapped cupsd even if a classically installed one is there in addition.
For the case that the user has only a classically installed CUPS and wants to use the queues there (because his printers need classically installed drivers) we have already thought about weird scenarios of force installing the CUPS Snap configured as a “firewall cupsd” receiving the job and passing on to the system’s classic cupsd, but this gets too complex.
My idea now to make it possible to generally allow auto-connection of the
cups plug would be to make the snapped user application drop any “lpadmin” (or generally system group) privileges, by some wrapper through which the actual application gets started. This way a classic CUPS rejects administrative inquiries, as the client process has now “lpadmin” group rights, even if the user who started the appication is member of the “lpadmin” group. Ideally this could be done by the
snapcraft-runner script. Then we even would not ned the addition mentioned above to force the printing of the application into the CUPS Snap if both snapped and classic CUPS are present.
Note that the “lpadmin” group exists in all classic systems with classically installed CUPS and it does not exist in distributions like Ubuntu Core, but here CUPS can only be installed as the Snap, so we do not need to care of the “lpadmin” group.
So my feature request is:
Make snapd be able to safely auto-connect the
cups plug of application Snaps in all cases, independent whether we use the CUPS Snap or any version of a classically installed CUPS
We need two measures to assure this:
- The CUPS Snap has Snap mediation. This is already implemented and working
snapd somehow drops “lpadmin” group privileges from snapped applications which do not plug
cups-control. This blocks admin inquiries on any classic CUPS. This needs to get added. I do not know whether one can do it in snapd or by modifying the
So we need to implement (2) for solving our problem.
Even better would be for Snaps and snapd in general, if fully confined Snaps generally drop all system group privileges and only if they plug
admin (or any variant of
admin or a special interface like “cups-control”) certain group privileges are conserved.