This directory needs to be somewhere that the client snap has access to, the client snap will not be cups (well except in the case of cups test utilities, but that’s a special case and can easily be handled separately), so it will not have access to /var/snap/cups. The directory you provided is the source of the bind mount, here I’m asking about the destination of the bind mount, i.e. somewhere in the foo snap that firefox would use to do printing things, the foo snap can only access /var/snap/foo/common, it cannot access /var/snap/cups/common, but using the bind mount we could put the cups snap socket inside the foo snap somewhere like /var/cups-snap/cups.sock that doesn’t conflict with anything else, and also the cups interface provides the necessary policy snippets to allow foo to access /var/cups-snap/cups.sock.
Unfortunately, currently in snapd only the content interface is allowed to be used with default-provider, however we may expand this policy, but expanding that policy I think will take a bit longer than the time to just change the cups interface, so this content interface is a short-term workaround as we enable default-provider for other interfaces like cups.
@ijohnson, thank you for the clarifications. The best would be if the bind-mount destination inside the confined Snaps which plug cups is /run/cups/cups.sock as a confined Snap cannot access the original /run/cups/cups.sock anyway, but if this is not allowed as bind-mount destination we need to use something else. Would be somewhere under /var/snap/cups or /var/snap possible as these directories cannot get accessed by the confined Snap anyway? Or could it perhaps be /var/run/cups-snap/cups.sock`?
So for the interface we have to go with two now? One content inmterface to trigger the dependency installation of the CUPS Snap and one named cups for all the rest? So then we have to go this way for now, and auto-connect both, to assure that if any confined Snap which prints gets installed that the CUPS Snap is also installed. We also need to add default-provider support for all (or at least more) interface types to snapd as soon as possible.
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:
- The
cups snap shall still slot the cups interface for client apps wishing to print to plug
- 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)
- Client snaps can plug
cups and they will get auto-connected to the slot exposed by the cups snap
- 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.
- 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.
- 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
- 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.
- 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:
- 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:
- expose the content interface slot that client snaps can use with default-provider as described above
- 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
@ijohnson, yes, this is excactly how everything should work!
So I will do the changes you asked for on the CUPS Snap. Would be great if you could post here the snapcraft.yaml snippets which I have to add.
We also need to tell to Snap developers what exactly they have to plug/add to their snapcraft.yaml in order to let their app print and also in order to let their app manage CUPS.
And we need to improve snapd so that who wants his app to print only plugs cups and everyone who wants his app to admin plugs cups-control and that’s it.
Sure, let me try and finish the snapd branch and then you can test with a snapd build to ensure it is all working end to end
1 Like
@ijohnson, OK, thanks, let us go this way.
So could you please post here what I have to change in the snapcraft.yaml of the CUPS Snap and what I have to add to the snapcraft.yaml of a user application Snap, once for a Snap which only wants to print and once for a Snap which wants to manage CUPS.
Mmmh slight complication we need to enable from the mount backend mounting on top of socket files, currently this is not allowed by snap-update-ns, but I have a patch which will enable this as well.
1 Like
Ah well we might actually have a problem with using /run/cups/cups.sock here since this causes mount namespace trespassing:
trespassing.go:224: DEBUG: trespassing violated "/run" while striving to "/run/cups/cups.sock"
since /run/ inside the snap’s mount namespace is shared with the host so if the file doesn’t already exist (i.e. cupsd is not running for whatever reason) then snap-update-ns attempts to create a “writable mimic” and this fails since creating the writable mimic would leak things to the host.
So I think we will actually need to go with a different directory that is not shared with the host, something like as I proposed before /var/cups-snap/cups.sock perhaps… we still would need the patch to enable mounting on top of socket files however. I’ll make these changes in the morning and share a full set of example programs and snapcraft.yaml’s when I’ve got it working end to end
1 Like
Yes, we should go this way for now. My only little concern is the /var/cups-snap/cups.sock which does not actually fit into the FHS but probably this is the only way to go to avoid clashes with the application and to not be in /run (/var/run is linked to /run, at least in Ubuntu).
The best would really be to offer the socket in the environment of the application on the original /run/cups/cups.sock but if it is not possible for security reasons, we have to live with something like /var/cups-snap/cups.sock.
Yeah it’s a bit unfortunate, since the typical top-level directory used for sockets, /run can’t really be used for this purpose since the snapd mount namespace code explicitly forbids modifications to the snap’s mount namespace that “leak” from the snap’s mount namespace to the host, and thus we can’t use /run for this bind mount location. If there’s a better location that is more FHS compliant I’d be happy to use something else
As a client (user application) Snap cannot see the CUPS Snap’s /var/snap/cups/common/... anyway, could it not simply bind-mount the CUPS Snap’s /var/snap/cups/common/run/cups.sock into the client Snap’s /var/snap/cups/common/run/cups.sock?
We technically could expose that, but we really don’t want to do that since that directory is $SNAP_COMMON for another snap and we don’t do that sort of sharing through interfaces - typically if one snap has something like a socket or other files that it wants to share and they exist in $SNAP_COMMON, they would be shared via the content interface as I initially suggested at the top of this post, however as @jamesh pointed out that can be brittle, so instead I am implementing a smaller subset of the content interface in a way that will not be quite so brittle, but doing so requires a choice of where to put the socket in the mount namespace of the client snap and putting it inside $SNAP_COMMON that corresponds to another snap is a very leaky abstraction.
But also to be clear if we went that route of just telling the client snaps to look at /var/snap/cups/common/run/cups.sock, we don’t even need a bind mount, that file will already be accessible, it is just denied via AppArmor since it is another snap’s data folder.
@ijohnson, so then /var/cups-snap/cups.sock is perhaps really the best solution? Then we should go this way and assure that the cups plug contains the setting of the CUPS_SERVER environment variable to make the application print via /var/cups-snap/cups.sock.
@ijohnson, anything new here? Please tell me when you have something for testing and tell me then, too, which changes I have to do in snapcraft.yaml of the CUPS Snap and of a test client Snap for correctly defining the needed slots and plugs and whatever else is needed.
Sorry this will have to wait until I am back next week, I will post something when I get back though I think the changes are now somewhat simpler to implement on the snapd side.
Alright I have a PR up which implements what I planned, it has a bit of a bug in that I seem to need to provide read / write rules for both the source and the destination of the bind mount which kinda defeats the purpose of the bind mount and I’m not sure why…
@ijohnson, thank you very much for the PR. Unfortunately, I cannot test it. I cannot find the snapd Snap you mean in the “Gihub Actions of the PR”. How do I proceed here?
@ijohnson, @jamesh, thanks a lot for the work on the PR which has finally landed now, available in the snapd on edge from tomorrow’s release on, and on stable from 2.55 on, expected in 2-3 weeks from now.
With this we will finally have safe printing from applications uploaded into the Snap Store. They simply need to have a “cups” plug which is supposed to get auto-connected to the “cups” slot of the CUPS Snap, the CUPS Snap being automatically installed along with the application Snap if it is not yet there.
On systems not having CUPS installed (unusual for desktop installations) the CUPS Snap will process the job and send it to the printer, if a classic (DEB, RPM, source, …) CUPS installation is present, the CUPS Snap will be a proxy, passing through print jobs to the system’s original CUPS but not allowing administrative CUPS requests. This way the user can always continue to use the print queues and drivers which he has used before. Installing a printing Snap does not require him to migrate his printing environment.
The most important part, implementing the “cups” interface including an appropriate security concept in snapd is now done, to finish, we need:
-
@ijohnson will file PR’s to the base snaps which will behind the scenes make using the cups interface more efficient, but that will not change how it’s used at all (it will just change the mount namespace setup by creating the
/var/cups directory there so we don’t have to do lots of mount tricks)
- Request to the Snap Store team here on the forum for permission for the CUPS Snap to use the
cups-socket-directory attribute and to get global auto-connect for the cups plugs in any package uploaded to the Snap Store be auto-connected to the cups slot of the CUPS Snap (the CUPS Snap being auto-installed as soon as the first Snap with cups plug gets installed).
- Implement the CUPS Snap auto-install as soon as a Snap plugging
cups gets installed.
I will soon request the interface auto-connection and post the link here.
1 Like
Note that all discussion during the last 8 months leading up to getting the PR merged have happened in the PR itself.
Now with the cups interface being implemented in snapd we only need to do some final steps before its launch.
To have an easy overview of the state-of-the-art and to not having the discussion getting lost in long threads I have started a new thread here in the forum to discuss the finalization.
