I’ve started to publish a new base snap to support repackaging Nix-built applications in a snap.
Nix uses a different file structure from most applications, and has special requirements of the filesystem. In particular, the only directory it requires is /nix. The snap I’ve published looks like this, with 23 directories, and 1 file:
/snap/nix-base/current
├── bin
├── dev
├── etc
├── home
├── media
├── meta
│ └── snap.yaml
├── nix
├── proc
├── root
├── run
├── snap
├── sys
├── tmp
├── usr
│ ├── lib
│ │ └── snapd
│ └── src
└── var
├── lib
│ └── snapd
├── log
├── snap
└── tmp
Snaps building on top of this layer will provide their own /nix with a layout:
layout:
/nix:
bind: $SNAP/nix
Inside /nix will include the complete closure of the Snap’s dependencies.
UPDATE (jdstrand): there is a limitation in the layouts implementation that doesn’t allow toplevel directories under ‘/’ to be created. Since nix requires ‘/nix’ (as opposed to /usr/nix or similar), a base snap is needed which contains the /nix directory.
@pedronis, this is a new and unique base snap where it only contains empty directories (meta/snap.yaml notwithstanding) for the required snapd mount points, plus /nix. This is needed because of the way nix operates-- @zyga-snapd and @grahamc came up with the idea that the snaps built which specify base: nix-base provide a /nix directory that has everything it needs to run and the bind layout ties them together. This all works in terms of security because the snap only executes what is in /nix (which is analgous to the snap executing anything in $SNAP) and therefore seccomp, apparmor (capabilities, signals, etc, etc) all work like normal. (Think of snaps that use base: nix-base sorta like statically linked binaries that use the bare base snap-- they need nothing else from the system or base and only use what they ship).
This snap is owned by the nix foundation and otherwise meets our base snap criteria as defined in Process for reviewing base snaps.
If you want to support desktop applications, I would suggest also adding the following empty directories too:
/usr/share/fonts
/usr/local/share/fonts
/var/cache/fontconfig
The desktop interface will try to mount the host file system fonts at these points. While it can use the “writable mimic” code to add mount points where they don’t exist, having the directories there simplifies things.
Given the approach and fundamentals of nix and the limitations of layouts vs the top level/root directory, this seems reasonable.
Just the usual reminder that once in use things can be added to the base but not removed. If for some reason a new version with different layouts would be needed it would need to be called nix-base-YYMM or something like that.
Yeah, we talked about that at the conference. The Nix layout (just /nix) has been stable since 2003 when it was first created. In that sense, it is almost unimaginable that we would create a different top level directory and still call it Nix.