Daniel Peebles (copumpkin) also has some ongoing work to use darwin sandboxes for pure builds on OS X. Perhaps we should try to generalize the interface for these things?
> On Dec 5, 2014, at 2:45 PM, Luca Bruno <[email protected]> wrote: > > Not a nix dev, but I think by adding an option to nix.conf to use pivot_root > makes the patch unobtrusive and easy to merge. > > On Thu, Dec 4, 2014 at 12:24 PM, Harald van Dijk <[email protected] > <mailto:[email protected]>> wrote: > Hello, > > I've recently been trying to use Nix in a somewhat different way than NixOS, > and the builders I've got, it would be useful if they were able to run > unshare -r. Unfortunately, while this command is normally available to > unprivileged users, it is for security reasons not available to unprivileged > users in a chroot environment. > > Reading up on how this works, I've come to understand that as one effect of > unshare -r is enabling chroot for unprivileged users, and the chroot > capability is well-known as being sufficient to break out of a chroot > directory, those security concerns are correct, and it is appropriate for > unshare -r to report an error if Nix is configured to use chroot. > > However, if chroot is combined with pivot_root, then the mount namespace root > and the process root are the same directory again. Since there is no longer > anything nothing to break out of, there is no risk of a user breaking out of > anything, and then, unshare -r _does_ work. > > A possible problem with pivot_root could have been that it lets the old root > remain available inside the new root, but that is easily prevented by > unmounting it afterwards. > > The attached patch (to Nix 1.7) to use pivot_root is mainly a > proof-of-concept, I know it is not appropriate in its current form. At the > very least, it should properly handle systems that lack a pivot_root syscall, > and even on systems that do have it, it might be better to make the use of > pivot_root optional (compile-time as well as run-time). > > Nonetheless, in its current form it is already useful for testing, which has > shown that it addresses the problem for me that I had hoped for it to > address, and that it does not cause problems for NixOS packages, which I do > continue to use alongside my own. > > Is there any interest in getting something like this in Nix? I would be > perfectly happy to clean this patch up, get it into better shape, but I'd > like to avoid doing so if (for whatever reason) it is decided that Nix should > not be using this. > > Cheers, > Harald van Dijk > > _______________________________________________ > nix-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.science.uu.nl/mailman/listinfo/nix-dev > <http://lists.science.uu.nl/mailman/listinfo/nix-dev> > > > > > -- > NixOS Linux <http://nixos.org/>_______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
