Suggestion: Unprivileged install via Bubblewrap

My development environment relies heavily on Nix, so I make it a point to install it wherever I can. Lately, I’ve been experimenting with a way to run Nix as an unprivileged user, through the sandbox used notably by Flatpak: Bubblewrap.
And I’ve been thinking: wouldn’t it be nice if the default Nix install script on nixos.org could deploy Nix within a local directory, using a Bubblewrap sandbox to bind the Nix store to a virtual root in the user’s environment?
Bubblewrap does not seem to require SUID, and is very frugal in library depdendencies, so a static binary wouldn’t be out of the question to bootstrap the sandboxing process.

For reference, here’s the script I am using. We could envision automatically detecting root-level directories and mapping them to the sandbox, to make it as transparent as possible.

2 Likes

the nix store just can’t be a symlink, but mount points should work fine.

One concern would be user IDs, as the nix multi-user will use dedicated nixbuild users. Single-user install I think just executes as you.

I’m kind of curious though, why doesn’t the install script work?

The current install script assumes that it can use sudo to create the /nix directory at the root (even as single-user), an assumption that doesn’t stand in an unprivileged environment. Also, I’m not seeking to replace the install process, but to complete it. I really don’t expect the multi-user install to work or benefit from Bubblewrap in the first place.

Ah, that’s what I thought, but I still think it’s a bit odd for a developer to not have sudo access. But this could also be on shared resources, where they don’t want dev’s to have privilege escalation, which I guess would make sense.

2 Likes

Just thought I’d mention that what you are describing seems to be what nix-portable is all about.

3 Likes

Well I’ll be. Looking into it, nix-portable doesn’t seem very flexible (no nix-env support?) compared to a full user session sandbox with a “real” Nix store at the root, and that seems to be because nix-portable attempts to provide the Nix binary right out of the box, which isn’t too useful given that the official Nix install script works within the sandboxed environment.

(Although nix-portable has potential for shipping a nix-shell environment within a Git repository, removing the need for a Nix install for contributors)

Consider larger corporate environments where it would be insane to allow this as a general policy.

4 Likes

I agree for stuff like “staging” “canary” or “prod” environments, but for development still odd. Even when I was in the Air Force working on TS/SCI networks, the development machines still allowed for privileged commands, but the entire network was air-gapped.

To me this suggestion is totally valid, the implementation details can vary a little bit, but definitely moving forward towards a more easy to get started Nix would be awesome!

5 Likes

Requirements aside, a sandbox-based Nix “install” method would benefit those who don’t want to alter their system state at all, only wanting to give it a quick spin, or even spinning up alternate Nix Stores for experimenting.

2 Likes

The main motivation behind nix-portable was to distribute applications which depend on nix without having the user to install nix first. Therefore nix-portable is designed to be a drop in replacement for the nix executable.

It was not targeted towards users who want to install nix and manage their user environment etc, though it could probably be extended for that.

But anyways I agree, having official support for proper sandboxed installations would be great.
Nix currently does support the --store flag that works with unprivileged namespaces, but still many of its operations depend on the environment being set up correctly. Therefore a proper installation is still required.

Alternatively nix could be changed to not do all these assumptions about the environment it currently does, and as a result make installation unnecessary.

2 Likes

Just noticed that Bubblewrap denies unprivileged mounts (which breaks AppImages), and has no breakout mechanism. Writing a userns wrapper with less security constraints is pretty much necessary if we were to make the unprivileged install a default in single-user mode.

Otherwise, we need to assume that a sudo-capable user wouldn’t use the unprivileged install mechanism, which would mean hiding it behind answering “No” to the “Can I use sudo?” question.

(then again, one could assume that a single-user Nix install doesn’t need AppImages, but I beg to differ )