Open tie opened 1 month ago
I think we should expose the sandbox in two ways:
a. Implement remote sessions in the daemon protocol b. Factor out the sandbox setup as a command or library, to make it available independently
I'd believe (a) is important for the derivation debugging user experience, especially when remote builders are involved, whereas (b) would also be a very sensible thing to do for architectural reasons, and your use case of course: testing.
Related:
Couldn't you already do this by ssh-ing or tmux-ing into an active build technically?
There's also the much wider and harder concern that you should be able to develop software with a compromised dev shell without having it compromise your machine.
Is your feature request related to a problem? Please describe.
When running
nix develop
(i.e. development shell), Nix does not apply any sandboxing measures that are present in the builder environment. It’d be nice to have some flag that would enable a subset of those, e.g. syscall filtering, if possible. Currently, it’s hard to develop and test a package that may perform some operations that are not valid inside sandbox but works in development shell.Describe the solution you'd like
There should be a way to run a development shell with a subset of restrictions that the actual sandboxed Nix builder environment uses.
Describe alternatives you've considered
Ensuring that packages do not depend on the sandbox environment (we currently don’t fail builds that violate sandbox restrictions). That is a bit cumbersome since it has to be done differently for each package.
__failOnSandboxViolation = true
derivation argument for opt-in sandbox enforcement. But since development shell inherits user’s environment (PATH, HOME, XDG stuff, other configs), there is no guarantee that some of these impurities don’t affect the build so that it fails inside the sandbox but not in the development shell.Additional context
n/a
Priorities
Add :+1: to issues you find important.