For the CUPS Snap (“cups”) I need two further interface auto-connections:
"cups-control" to "cups:admin"
After applying the new security concept of allowing client Snaps only to do administrative tasks on CUPS if they plug CUPS “admin” slot with their “cups-control” plug also the tools which come with the CUPS Snap suffer this restriction, like the lpadmin and the cups-browsed. To make them work one needs to make the CUPS Snap bite in its own tail via
sudo snap connect cups:cups-control cups:admin
Can this be made automatic?
"network-manager-observe" cups-browsed communicates with Network Manager to get note of changes of the host name of the machine it is running on. Therefore it needs this interface.
Could this also be automatically connected?
specifically the slot-snap-id bit such that if there are multiple slots available on the system, specifically the one provided by the cups snap is used to auto-connect. This is more than a hypothetical concern about some fork of the cups snap, because on classic systems, snapd itself will provide a cups-control slot, so in order for the auto-connection to work, it needs to be scoped like this AIUI.
The CUPS Snap needs another bite into its own tail, equivalent to auto-connecting the cups:cups-control plug to the cups:admin slot, we also need to auto-connect the cups:cups plug to the cups:printing slot. So all auto-connections we need are
Did this request also cover automatically connecting third-party snaps using the cups interface to the cups snap (equivalent to snap connect gimp:cups cups:printing for gimp)?
Yes, this is essentially important for the user experience.
Ideally it should be that if the CUPS Snap is installed, all other Snaps plugging “cups” should automatically plug to the “printing” slot of the CUPS Snap, and if the CUPS Snap is absent, to the system’s slot.
For “cups-control” the same with “admin” of the CUPS Snap, once the “cups-control” was either connected manually or permitted for auto-connection by the Snap Store team.
On this subject, do we expect snaps with a cups plug to function on systems without the CUPS snap installed? Currently cups-control is implicit on classic systems, but cups isn’t. That’s going to make it more difficult to convince application snaps to migrate off of the interface that grants admin access.
And if we do make cups an implicit interface, we’d now have two candidate slots for application snaps to connect to if the CUPS snap is installed. We could make things auto-connect in this case by making the slots slots-per-plug: * so apps connect to both slots simultaneously. It’s not ideal (since the app will only be talking to the cupsd from one of those locations), but should generate workable AppArmor profiles.
@lucyllewy, is this possible with current snapd? Or would this need changes on snapd?
Also, if snapd pulls in the CUPS Snap automatically, it can come to problems:
Currently, if you install the CUPS Snap and there is already a classic installation of CUPS, the CUPS Snap’s cupsd will run in parallel on port 10631, so the CUPS used by default stays the classic one.
In the future, there will be also a migration possibility, which would mean that the CUPS Snap gets installed and the classic CUPS removed, overtaking all configuration (queues, …) into the CUPS Snap. This requires all classic drivers retro-fitted into Printer Application Snaps, as classic drivers are not supported by the CUPS Snap. Also this migration will most probably not be triggered by the CUPS Snap itself as it is not able to uninstall a classically installed package, but rather by some distro package manager performing a general update, for example to a new distro release, and doing the migration as part of it. I will add the script to overtake the configuration to the Snap, but only later, if I have more Printer Applications for testing.
Also at least for Ubuntu the installation of a user application Snap which prints does not necessarily need to migrate CUPS to the Snap automatically, as the Ubuntu package of CUPS has the same security feature for administrative inquiries to the CUPS daemon as the Snap. It checks the same way whether the inquiry is from a fully confined Snap and if so, only allows it if the Snap plugs “cups-control”.
So for now let us apply the three auto-connections I have asked for in the beginning of this thread as we have the needed 3 votes for them.
Yes, the cups plug should also work with no CUPS Snap installed. It should work the same way as cups-control, being implicit on classic systems. From the Snap Store auto-connection side cups should auto-connect by default and cups-control should only auto-connect if the Snap Store team has approved the Snap requesting this. Existing Snaps which plug cups-controlfor the sole sake of printing should switch to cups.
Your slots-per-plug: * idea should even work, as the client app will connect to CUPS through the standard resources, /run/cups/cups.sock and localhost:631. If only the CUPS Snap is installed, these resources are used by the CUPS Snap, if a classic CUPS is installed, independent whether there is the CUPS Snap in addition, these resources lead to the classic CUPS. So if the app plugs both slots, the communication always goes to the correct, expected CUPS. And both CUPS are protected against administrative tasks from fully confined Snaps plugging only cups.
So let us go the slots-per-plug: * way. Do I have to change something in the CUPS Snap for that and if yes, tell me what. And tell me if I have to change it immediately or wait for some change in snapd or so.
