Enable content interface type between Classic confinement snaps

snapcraft
1

.NET Core snaps need to run under Classic confinement. The framework supports targeting of multiple versions of the runtime so there is a scenario wherein a developer will have the latest tooling (.NET Core SDK) but need to either develop against a different runtime than is supplied with the tools.

Working with @sergiusens, we have confirmed the scenario is enabled through content interfaces. However, content interfaces are currently not supported between Classic confinement snaps.

This is a request to consider enabling content interface connections between Classic snaps.

Regards,
Lee

1 Like
2

There shouldn’t be any problem with a classic confined snap providing a content interface slot to share some of its files with other snaps.

The plug side is problematic because classic snaps run in the host system mount namespace. You’d never see any content interface bind mounts because they are performed while configuring the strict confinement sandbox mount namespace.

With that said, classic snaps run with a wide open AppArmor profile, so there is nothing to prevent them from reading another snap’s files directly without the help of the content interface. You could probably get by with a symlink to the other snap’s content instead of a bind mount.

It wouldn’t be completely impossible to support content interface for bind mounts (e.g. generate systemd .mount units to perform the bind mounts on startup, similar to how the snaps themselves are mounted), but it would be good to check if any of the other solutions are workable first.

3

What I’m doing here is to just set symlinks inside the classic snaps to the content interfaces I wanted to do at staging level (with a script).

However, since this is something that is already defined in the snapcraft.yaml it would be nice if that could be done automatically by snapcraft.

I mean if the snap is classic and we’ve something like

plugs:
  my-content:
    interface: content
    target: $SNAP/my-content
    default-provider: content-provider

Snapcraft automatically creates a symlink in prime/my-plug pointing to /snap/content-provider/current', as in classic having /snap` is an assumption anyways.

@sergiusens, any toughs?

4

I am not fond of parsing information relevant to snapd and applying it at build time in snapcraft.

5

I think that we need to come up with proper support in snapd but as it was already stated, this is not easy because classically confined snaps run in the mount namespace of the host so we cannot bind mount anything willy-nilly because that will affect all the other snaps and apps on the system.

There’s ongoing work / investigation to allow classically confined snaps to use snap instances (where a single snap is installed multiple times under different names) that suggests we need to use a mount namespace after all, just one that is different from what is normally done. Still, that would not be a namespace that can be updated at runtime and that’s the requirement for content interface connections to work.

The bottom line is that I think we need to show a clear rationale and examples of how this is really useful and how the application cannot achieve this by itself (since it is not really confined)

6

For what it’s worth, the work in snapd to enable parallel instances of classic snaps (which creates the new mount namespace for the parallel instances) landed a while ago, albeit still as experimental but something like this could now conceivably be implemented if use cases were presented.

7

We adopted the content interface for the certification checkbox tool. It allows us to keep core runtime and public test providers in a snap and create small snaps to define only apps and per projects additional tests (private stuff most of the time).

This kind of split works really well on UC since cert is a publisher of both snaps thus allowing auto-connections of those interfaces.

But we do propose checkbox apps in classic snaps too with the same logic. A big checkbox-core snap with runtime and public components and little apps-only classic snaps . It works for us as our installation guideline instructs users to install the checkbox-core snap beforehand.

I’d love to see a mechanism to free us from this extra step on classic. here’s our use case.

8

My use case is a GNOME-aligned app that needs to use classic confinement. I’d like to use the same gnome platform content snap that the gnome snapcraft extensions do. It might make my packaging simpler, and would certainly reduce my snap size.

I don’t necessarily need the bind mount part of the content interface. I can just point at /snap/gnome-3-38-xxxx/current/.

But I would love to have the default-provider auto installation part of the content interface. Without that, I have to keep bundling the content.

1 Like