Add sandboxed building for FreeBSD using jails#9968
Add sandboxed building for FreeBSD using jails#9968rhelmot wants to merge 5 commits intoNixOS:masterfrom
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
github-actions
bot
added
the
with-tests
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-02-12-nix-team-meeting-minutes-123/39775/1 |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This is the utility changes from #9968, which were easier to rebase first.
This is the utility changes from #9968, which were easier to rebase first. I (@Ericson2314) didn't write this code; I just rebased it. Co-Authored-By: Artemis Tosini <me@artem.ist> Co-Authored-By: Audrey Dutcher <audrey@rhelmot.io>
Ericson2314
force-pushed
the
freebsd
branch
5 times, most recently
from
6e711ce to
d1a4478
Compare
| // There's also just no simple way to do this correctly, you have to manually | ||
| // inotify watch the files for changes on the outside and update the sandbox | ||
| // while the build is running (or at least that's what Flatpak does). | ||
| // | ||
| // I also just generally feel icky about modifying sandbox state under a build, | ||
| // even though it really shouldn't be a big deal. -K900 |
There was a problem hiding this comment.
Does this mean this needs proper attribution to k900? Is this somehow cherry-picked from Lix?
There was a problem hiding this comment.
Added a second change id and a co-authored-by
|
|
||
| void startChild() override | ||
| { | ||
| int jid; |
There was a problem hiding this comment.
Why the local variable? We should be able to assign directly to the AutoRemoveJail and work with just a single variable instead of 2.
There was a problem hiding this comment.
Is this good now? I kept the local variable with a very minimal scope so I wouldn't assign it with a negative number.
There was a problem hiding this comment.
Or maybe we don't need the del variable at all.
|
I'm happy to work with @xokdvium to land these C++ best practices changes. @rhelmot what would be a better use of your time and unique knowledge is retroactively reviewing the rest of what I did in #13281 that this PR doesn't touch. In particular it would be nice if we can get rid of the FreeBSD-only argument to |
Ericson2314
force-pushed
the
freebsd
branch
3 times, most recently
from
ce31fa1 to
209a5f1
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Ericson2314
force-pushed
the
freebsd
branch
3 times, most recently
from
47d8794 to
01fe2d5
Compare
|
This one has been held up for a while, but there is one last PR I would like to hold it up for, which is #14788. That should hopefully be removed momentarily. The interaction is that it reworks the cleanup of In the meantime, @xokdvium, what do you think of the "Clean up |
Done! |
|
Before the recent rebases (9799fcb) it was working but seems to be broken now: |
- Create methods for what the destructors call. Arguably `reset` should use this, to make it more consistent with smart pointers in the standard library. - Use `std::filesystem::path` in `AutoRemoveJail` - Remove `del` from `AutoRemoveJail` because it is not needed.
The <() process substitution syntax doesn't work for this one testcase in bash for FreeBSD. The exact reason for this is unknown, possibly to do with pipe vs file vs fifo EOF behavior. The prior behavior was this test hanging forever, with no children of the bash process. Change-Id: I71822a4b9dea6059b34300568256c5b7848109ac (cherry picked from commit ae628d4)
Adapted from Change-Id I071e6ae7e220884690b788d94f480866f428db71 This will be used in the next commit. Co-authored-by: K900 <me@0upti.me>
New FreeBSD sandboxes are based on jails and chroots. They provide fairly similar capabilities to sandboxes on Linux and allow for pure builds of FreeBSD nixpkgs. Although it would also be possble to use jails for Linux emulation, that is not supported with this commit. Change-Id: I619e1e34c56de7aaa64a38408210a410bb13adba Change-Id: I071e6ae7e220884690b788d94f480866f428db71 Co-Authored-By: Artemis Tosini <me@artem.ist> Co-Authored-By: K900 <me@0upti.me> Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems> Co-authored-by: Sergei Zimmerman <sergei@zimmerman.foo>
8 participants
Motivation
Build isolation is good! In Linux, this is accomplished with namespaces (containers). The equivalent technology on FreeBSD is jails.
Context
This is part of my ongoing project to make FreeBSD a first class citizen in the nix world.
This was a fairly simple patch, just needed to add parallel implementations for all the sandboxed Linux build pieces.
The most fragile part of this implementation is the fact that there is a lot of global state that gets set up in order to construct the jail - the chroot dir in the nix store, the nullfs mounts (the FreeBSD equivalent of a bind mount), and the jail ID itself. Lots of steps have been taken to make sure these all get cleaned up, both at the end of the build and at the start of any rebuilds. It seems to be resilient to interruption.
This has been live-fire tested with my fork of nixpkgs for FreeBSD. It is able to build the stdenv without issue.
Please squash-merge this PR! It includes some changes that were later reverted, which don’t belong in this repository but instead in the FreeBSD ports repository.
Priorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.