Before we can discuss today’s topic I need to untangle a rather confusing concept. Snapd cares about naming a lot. We really try to do our best to name things in a consistent and clear way. We don’t like to create error messages from hell and force the user to google crap to understand what the computer just said.
Well, we didn’t get one thing right though: the term classic, currently, may refer to:
- classic distribution that uses an existing package system (debs/rpms) in addition to snaps
- classic snap that one can install on Ubuntu core (which is not a classic distribution as it uses snaps exclusively) to get classic Ubuntu with apt-get and writable-anywhere file system
- classic confinement that a snap can request to effectively have no confinement at all (like in a classic distribution)
Today we’re talking about that last thing.
About classic confinement
Classic confinement is a very simple idea. Move your application into a snap easier than before by taking one element out of the equation. Disable confinement and file system redirection entirely to get started faster (and by get started, I mean get started with making a snap).
This has the advantage of still having access to snap features such as channels
and a way to update the software easily and has some sense of security through
the assertion system that at ensures that we know where the software is coming
from. This alone makes it better than
curl | sh -c that many upstream
projects recommend as their official installation instructions. Even if someone
goes rogue / malicious and betrays our initial trust, we can smite such
offenders (or the offending package revisions) and pull the snap from the store
as fast as possible in order to limit damage.
Digression: We (the snapd team) are paranoid about security and even when the system is no longer shielded from the application the store has a strong policy for well-behaved, well-known FOSS projects as the only allowed providers of snaps using classic confinement. In many ways this is similar to what you get with regular Debian packages (most of them are not using confinement and even if they do, they must do so voluntarily) except for the all-stop freeze-the-archive periods and a way to reuse dependencies from the distribution.
Your application can rely on the core snap and on whatever it brings by itself and is free to try to use anything on the classic distribution file system but if it does then all bets are off.
So far so good. I personally think that it is a great way to deliver developer tools like compilers or interpreters or system administration tools. Anytime where you want them to operate on your system as it really exists and not be stuck in some hidden complex machinery that ensures uniformity across diverse systems.
The idea is pretty good but as things stand today it is not that easy to use.
snap-confine helps to run an application using classic
confinement it behaves in a special way. It no longer enables apparmor, apply a
seccomp profile, do any tricks with mount name spaces or bind mounts. It is
just a pass-through to your application.
Building classic-confinement snaps with snapcraft was (and I think, still is) a
bit bumpy. When we initially discussed this problem we realized that without
control of the mount name space we must rely on building the software in a way
that would force it to use resources from the core snap before it tried to look
at the likes of
/usr which may contain entirely incompatible stuff
and lead to crashes.
We set a few simple assumptions here:
- the executable must use the dynamic linker from the core snap
- the executable must be linked to the libraries from the core snap or from its own snap
- the executable must be built in a way that lets it find resource files in its own snap.
With those three assumptions you and the bag of predictable low-level libraries in the core snap you can run your software on pretty much any Linux distribution.
All you need to do is to provide a few build-time configuration options, a few switches to the linker and you’re done. This means that you cannot easily reuse pre-build software. Why? Because it would have none of the magic that makes it do the three things I just listed.
People tried and ran into this issue pretty quickly. If you’re familiar with how things work at that level and you feel comfortable with building your software from source (and you should be if you want to build a snap, after all, it is your software, snaps empower deveopers to ship software) you could build the software from source, with just the right set of options in order to avoid it but it doesn’t feel like a very good and easy story.
If classic confinement was not useful as an entry into the world of snaps it makes little sense to spend time and effort on. We started looking for options and after a few discussions ran into this idea.
Since launchers that allow you to run any snap application are managed by snapd, we can use them to redirect the dynamic linker on unmodified binaries.
Technically we can make the
snap run ->
do what we want. At the very last stage
snap-exec, instead of just running
the application, we can run the dynamic linker with command line option to
change the search path to just the core snap and the application’s own snap.
Then, for as long as the application doesn’t need to run extra executables from
the core snap or from its own snap, things should generally work.
There will still be rough edges. Pre-compiled software will still load data
/usr/share, look at configuration files in
/etc (possibly this is not
a problem but it depends on fine details). The most serious problem is with
applications that internally run other programs. If they attempt to run a
program from their own snap (which is perfectly reasonable thing for a snap to
do) two things will happen:
- the kernel will resolve the dynamic linker to use
- the linker will resolve the dynamic libraries to link
Both of those will not be the carefully overridden values we need to provide to
make things work. What is even worse is that because we don’t want to pollute
the environment with variables such as
PATH (as that
would mostly prevent applications from the classic distribution from working)
the child will no longer be able to run anything from the snappy world without
having to pass through the generated application launchers.
One way of tackling that problem would be to enumerate all the executables in the core snap and in the snap that is being started and generate internal launchers for all the executables seen there. Then a directory with all such launchers could be placed on PATH so that they would be found when searched for. The launchers would just ensure the linker switch happens when it is required.
Still this is not perfect. What if an application happens to try to run an
executable with the full path? Say
/snap/core/current/bin/true. Then we are
back to square one and all the problems resurface.
One, perhaps somewhat invasive, option would be to bind mount the shadow launchers over all the executables in the core snap and in all the snaps that are using classic confinement. Then there would be no way to run anything without going through a part of snapd that makes the magic happen.
I think this would be a bit messy though. The output of
mount might make a
sysadmin raise an eye-brow or reconsider to move to the countryside and herd
What is the price that needs to be paid to maintain the illusion of seamless access to any pre-compiled application binary running on any Linux distribution?
It is possible to create snaps that use classic confinement and they will work correctly across a wide variety of environments but the process is not as easy as we would like.
If you build your software from source use:
--prefix=/snap/$SNAP_NAME/current/usr and re-locate the code so that on
install only the
usr directory is present in the snap. Using snapcraft, or
directly, use the right dynamic linker
(-Wl,--dynamic-linker=...). Use the
libraries from the core snap using rpath (
-Wl,rpath,...) and things will just
As soon as we make the changes you can drop the last two elements and perhaps even switch to pre-build software from another source. I will post an update when this happens. All the existing snaps using classic confinement will work as before but new builds can then drop the extra complexity.