-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Automatic UID allocation #3600
Automatic UID allocation #3600
Conversation
A few questions/comments:
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
I think I have heard of people trying to run systemd on NixOS using only cgroup2; and also, of course, I wonder what will be eventually needed to run lighter-weight NixOS tests on non-NixOS Linux. I guess creating a |
This comment was marked as outdated.
This comment was marked as outdated.
Once things are configured: I do get «Container nixos exited successfully.», and the target path is built with reasonable output (and there is a running Logs: firewall failing seems expected,
Overall |
Looked at the code and got an idea to test… |
Yeah that's currently true, didn't think about that. In principle however it could use any existing hierarchy since it's only used for tracking processes. |
… or even mount «nix» hierarchy if I am OK with mounting |
Actually that succeeds for me. Which makes me realize a big problem with this approach: whether certain networking features (firewall, NAT, ...) work depend on what kernel modules are loaded in the host system. I don't think there is any way to restrict access... |
Erm. Does that require structured required features (and, in this instance, assertions about host kernel modules) for a proper-ish solution? I guess whoever cares could write a very minimal |
Or maybe a seccomp filter could be used to restrict access to undeclared features. |
Seccomp filter sounds like something that requires ahead-of-time enumeration of all possible things that could go wrong |
I just realized that the situation isn't that bad. Or rather, it was already bad and this doesn't make it worse. It was already possible to create network devices, firewall tables etc. depending on the host kernel configuration. For example:
This will even cause kernel modules like |
Ah, it might be that the host dependency got exposed by the fact that I did not enable module autoloading. I guess this impurity was «mitigated» by there being little incentive to do such things in public expressions. |
90b4689
to
e263fd4
Compare
Rather than rely on a nixbld group, we now allocate UIDs/GIDs dynamically starting at a configurable ID (872415232 by default). Also, we allocate 2^18 UIDs and GIDs per build, and run the build as root in its UID namespace. (This should not be the default since it breaks some builds. We probably should enable this conditional on a requiredSystemFeature.) The goal is to be able to run (NixOS) containers in a build. However, this will also require some cgroup initialisation. The 2^18 UIDs/GIDs is intended to provide enough ID space to run multiple containers per build, e.g. for distributed NixOS tests.
Also, run builds in a cgroup namespace (ensuring /proc/self/cgroup doesn't leak information about the outside world) and mount /sys. This enables running systemd-nspawn and thus NixOS containers in a Nix build.
2^18 was overkill. The idea was to enable multiple containers to run inside a build. However, those containers can use the same UID range - we don't really care about perfect isolation between containers inside a build.
"uid-range" provides 65536 UIDs to a build and runs the build as root in its user namespace. "systemd-cgroup" allows the build to mount the systemd cgroup controller (needed for running systemd-nspawn and NixOS containers). Also, add a configuration option "auto-allocate-uids" which is needed to enable these features, and some experimental feature gates. So to enable support for containers you need the following in nix.conf: experimental-features = auto-allocate-uids systemd-cgroup auto-allocate-uids = true system-features = uid-range systemd-cgroup
Maybe this should be a separate system feature... /sys exposes a lot of impure info about the host system.
e263fd4
to
7349f25
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2022-11-14-nix-team-meeting-minutes-8/23452/1 |
sandbox uids. This must be done before any chownToBuilder() | ||
calls. */ | ||
killSandbox(false); | ||
|
||
/* Right platform? */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason this code is no longer at the top? It makes sense to me to check the drv itself before doing IO like checking the filesystem --- cheap checks first.
|
||
/* FIXME: set proper permissions in restorePath() so | ||
we don't have to do another traversal. */ | ||
canonicalisePathMetaData(actualPath, {}, inodesSeen); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This just become needed?
@@ -580,10 +642,11 @@ void LocalDerivationGoal::startBuilder() | |||
|
|||
printMsg(lvlChatty, format("setting up chroot environment in '%1%'") % chrootRootDir); | |||
|
|||
if (mkdir(chrootRootDir.c_str(), 0750) == -1) | |||
// FIXME: make this 0700 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This FIXME is fairly short so I doubt I would know how to interpret it a long time from know. Should we file an issue and link it here?
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
This is nice, but it breaks nix-top which gets build users from the |
@ncfavier Maybe you can create an issue for querying active builds? But maybe it's less important since in principle builds will show up in |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/nix-team-report-2022-10-2023-03/27486/1 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
This PR does the following:
It adds an experimental feature and option
auto-uid-allocation
which provides an alternative to having anixbld
group of pre-created build users. When enabled, Nix allocates UIDs/GIDs in the range 872415232+ on Linux and 56930 on macOS.It adds an experimental feature
cgroups
that causes builds to be executed in a cgroup. This allows getting some statistics from a build (such as CPU time) and in the future may allow setting resource limits. But it mainly exists because theuid-range
feature requires it.It adds a system feature
uid-range
that causes a build to be executed as root in a UID namespace with 65,536 UIDs available. This allows things likesystemd-nspawn
and NixOS containers to run inside a Nix build.