But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.
Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaining the system itself.
I never asked around so maybe that's on me. Debian works just fine though and containers are (usually) simple enough for me to wrap my head around.
I didn't end up using Flatpak for the same reason.
When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no?
The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.
I'm not suggesting the presence of a vulnerability just that I'm not comfortable switching to a complex system where I have little to no understanding of the logic behind the design. My remarks were nothing more than a tangential gripe.
NixOS is incredibly complicated at build time, but the filesystem & runtime state is pretty simple. Run it in a VM and look around, there's very little magic at runtime; the trickery is mostly in the build time rpath hack to load shared libs from the specific /nix/store paths, and a lot of configuring software to read files from specific /nix/store paths.
