Skip to content

nix-daemon: default useSandbox to true #22767

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 14, 2017

Conversation

grahamc
Copy link
Member

@grahamc grahamc commented Feb 13, 2017

Motivation for this change
Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

Sorry, something went wrong.

Verified

This commit was signed with the committer’s verified signature. The key has expired.
vdemeester Vincent Demeester
@mention-bot
Copy link

@grahamc, thanks for your PR! By analyzing the history of the files in this pull request, we identified @stapelberg, @mbravenboer and @MarcWeber to be potential reviewers.

@grahamc
Copy link
Member Author

grahamc commented Feb 13, 2017

@edolstra @globin

@edolstra
Copy link
Member

See NixOS/nix#179.

@grahamc
Copy link
Member Author

grahamc commented Feb 14, 2017

Is NixOS/nix#179 a blolcker on this, though? /cc @copumpkin @vcunat

@copumpkin
Copy link
Member

It's a policy decision, really. I think keeping sandboxes on is a better default, more in keeping with the "nix philosophy" as I interpret it, and will also get more people caring about the sandbox speed and offering to fix it 😉

@copumpkin
Copy link
Member

I think it'd be a huge step forward for the 17.03 release. @edolstra are functions like pkgs.writeText and other applications of builtins.toFile even affected by sandboxes? It seems like the biggest concern here would be a ton of tiny config files on NixOS, but don't many of them get generated by toFile?

@grahamc
Copy link
Member Author

grahamc commented Feb 14, 2017

with the approval from globin, copumpkin's enthusiasm, and vcunat's 👍 I'm taking Eelco's link as just "for reference" than an objection, and merging :)

@grahamc grahamc merged commit 3be1388 into NixOS:master Feb 14, 2017
@grahamc grahamc deleted the sandbox-by-default branch February 14, 2017 18:58
@edolstra
Copy link
Member

I'm 👎 on this. The performance problem affects everybody, while the purity issue isn't much of a big deal.

@grahamc
Copy link
Member Author

grahamc commented Feb 14, 2017

Reverted in 7483ba0

@copumpkin
Copy link
Member

I think the purity issue is a pretty big deal, but mostly outside of NixOS, so I'm not too hung up on this 😄 lack of default purity on darwin and non-NixOS linuxes can be very annoying, leading to countless hours of wasted time because some build tool "helpfully" decided to pick up something from the host's FHS filesystem.

@edolstra
Copy link
Member

But Nix packages should build with and without sandboxing, since sandboxing is not compulsory. So it's not wasted time :-)

@copumpkin
Copy link
Member

copumpkin commented Feb 14, 2017

Well, I'd like for it to become compulsory eventually (once we resolve the performance issues and the darwin sandbox problems), because those types of failures are generally quiet and very hard to diagnose, and I'd rather spend my time packaging rather than struggling with cmake's arcane rules for reaching into all sorts of places it shouldn't be looking.

@vcunat
Copy link
Member

vcunat commented Feb 14, 2017

I agree it's about policy. It's machine time vs. human time.

@qknight
Copy link
Member

qknight commented Jun 25, 2017

@edolstra i understand the efficiency argument but for those who want fast builds, they can disable sandboxing. basically a priority swap which i would like very much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants