I haven't looked at userns mappings in a while, but does this have security implications?

see #2525

@copumpkin: The only security implication to the best of my knowledge[1] are:

1. setuid/setgid binaries become callable and effectively assume root
2. SCM_CREDENTIALS passed over a socket are not squashed to nobody (and subsequently can be passed out).

I do think that the general assumption is that we do not trust code executed in the build sandbox, therefore minimising attack surface seems worthwhile. While I don't have any solution for Point 2, I do think that this scenario is quite unlikely as it would require a cooperating process outside of the sandbox, which then again could be used to leverage attacks in the first place. Point 1 can tackled by remounting all bind mounts to nosuid. I will amend the PR for the latter.

[1] See the two section above "CONFORMING TO" for both of these references. Caveat: There is no exhausting list on what kernel facilities might use uid translations. I do however think that a manpage as recent as this (2018-02-02) would list the most critical points.

Making this change unconditionally will make use of the sandbox require running Nix with privileges. Currently using the Nix sandbox does not require privileges, so this change at least should be behind an option, and preferably off by default.

Making this change unconditionally will make use of the sandbox require running Nix with privileges. Currently using the Nix sandbox does not require privileges, so this change at least should be behind an option, and preferably off by default.

I am not aware that that's the case. I have used this with unprivileged nix-bld users in the past.

@clefru I think the question is whether a single-user installation with unprivileged Nix daemon can use sandboxing.

@7c6f434c / @catern : I revisited your concerns about single-user installations and you are correct that this patch would break these installations. I was under the impression that unprivileged processes are free to write multiple uid mappings but they must only write a single mapping:

          +  The data written to uid_map (gid_map) must consist of a sin‐
          gle line that maps the writing process's effective user ID
          (group ID) in the parent user namespace to a user ID (group
          ID) in the user namespace.

from http://man7.org/linux/man-pages/man7/user_namespaces.7.html

To recap: The underlying problem is that some build processes might persist their uid-(un)mapped view on /nix/store in some way, or in other words copy something out of the nix store and preserve ownership. NixOS/nixops#931 persists a 9p-mounted nix/store via rsync from inside a VM, so the qemu VM process running inside the builder sees nix/store other than $OUT as "nobody:nobody", and hence the 9pfs server sees that owner, hands it to the VM, and rsync inside the VM creates nobody:nobody owned files, which later breaks the image.

I do think that there is NO way to achieve a consistent view on /nix/store with plain uid maps. uid maps need to be bijective, and I assert there is no bijective map between the single user views and the NixOS views, because we have:

                                  Single-user   NixOS
1. Build process see $OUT as:     nix-bld       nix-bld
2. Build process see !$OUT as:    nix-bld       nobody
3. /nix/store real owner:         uid           root

and Line 1 & Line 2 cannot be unified with a bijection.

While we could play some tricks inside the build process using specially crafted fuse file systems, I don't think that this is worth the effort. I'd rather say that "no build process is to preserve ownership of other /nix/store components". I fixed NixOS/nixops#931 this way. Therefore, I am closing this PR.

As towards #2525 I have no strong feeling either way as the PR tries to achieve something different.