-
-
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
distributed builds require a trusted remote user #2789
Comments
I have stumbled upon this in a different situation. My remote non-NixOS machine has already had my user in |
This requirement means that sharing a build cluster across multiple users makes them all susceptible to a cache poisoning attack (e.g. if one user's machine is compromised then anything can be copied into the build server's Nix store). I asked @grahamc about a more secure method and he mentioned an possible approach where
which avoids the possibility of cache poisoning because everything in a |
That's how remote builds used to work, but it's inefficient to copy the drv closure. That's why |
Is there a reason we can't have both? |
Yes please let's have both. One gotcha, A derivation can directly refer to a store path direclty (rather than derivation that built it) for sake of store paths with no associated derivation. But say the store path is associated with a derivation? We should outright either ban that, or ensure the derivation is fixed output so the remote builder's drv->build trust mapping isn't grown. |
Is there a reason why adding your user as a It seems strange that I think @arcnmx asked this question in their initial post, but it doesn't appear to be answered in this thread. (Unless it actually has been answered and I just don't understand the answer...) |
It seems strange that `trusted-user` is required, even though in most(?) cases you would be able to directly `ssh` to the remote machine and run `nix-build`, which works without being a `trusted-user`.
The way distributed builds work with Nix, you are supposed not only to be able to trigger a build on a remote machine, but also to export some locally-available build results to the remote machine and make it accept it. If you have two remote builders, and you change stdenv, and the first one has built glibc, you want just to copy this glibc to the second builder instead of building it again. And importing a non-fixed-output store path (bypassing the build) requires some way of establishing trust.
|
@cdepillabout See above. Remote builds don't use the same mechanism as local builds. They use a special API called |
See NixOS/nix#2789 I thought using builder-use-substitutes = true might be enough, and it seemed to work for whatever reason... (Perhaps my config removing trust from bob was not fully activated? Or perhaps I happened to have had all the necessary derivations on tobati already.) Anyway, these errors came back: error: you are not privileged to build derivations error: unexpected end-of-file So switching back to the trusted user approach.
@edolstra Can you explain this comment and integrity issues that come from allowing untrusted users from uploading arbitrary Also, surely the remote machine needs more that just the top-level .drv file. In order to build all the dependencies it will need the the .drv of all the the dependencies down to the the ones that the remote machine has already built, but this is exactly the set of .drv files that nix-copy-closure needs to send. (I do get that if the local machine is sending the remote machine build outputs, then, of course the local machine needs to be trusted.) |
Okay, after reviewing page 108 of edolstra's thesis I now see that Edit: hashDrv is used to create the output field of a valid .drv file, not the store hash of the .drv file (which is based on the contents of the .drv file). This is what edolstra means by not being able to validate the output fields of drv files without the contents of the input drv files. Though I still don't quite understand why this needs to be done. |
I've started to fix this. I'll link this in the PRs which relate to it. |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/obsidian-systems-is-excited-to-bring-ipfs-support-to-nix/7375/35 |
I marked this as stale due to inactivity. → More info |
I am still interested in this being resolved |
I marked this as stale due to inactivity. → More info |
Not stale |
#3921 this is the PR, for the record. |
I marked this as stale due to inactivity. → More info |
Not stale, still an issue |
Discussed in the Nix team meeting:
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-03-23-nix-team-meeting-minutes-43/26758/1 |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-03-27-nix-team-meeting-minutes-44/26759/1 |
@Ericson2314 I understand a fix has landed in Nix 2.16. I'd like to allow trustless remote builds for some users on my machine. Could you please clarify whether
for trustless remote builds to work? Thank you! |
I am pretty sure at least this. If that doesn't work, try updating both sides. |
I don't understand how the PR addresses the issue. When a local trusted user runs: Local: |
@MathiasSven I saw the same thing, but then switched from |
For those using NixOS, I had to add
to my |
I just walked right into that issue and found the error-message thoroughly unhelpful:
While putting Another issue is, that if you use singing, the ssh-ng way results in errors of this kind: |
By "pops up" you mean appears in web search results? We can only do so much about that. @Ericson2314 could we cheaply improve the error message here? It seems like inferring from the circumstances what the correct steps would be is not exactly trivial.
I'm not exactly sure, but |
Mostly yes, but I also heard this answer from people in the community. A nice error message when that occurs on a remote build would probably, eventually cure both.
Yeah, I probably have something configured badly, but I find it strange that everything build when the build-user is trusted. Should it not As a side-note, if you happen to read this and can invite me to the nixos-org so I can keep on maintaining packages effectively, I'd appreciate it. I missed my automatic invite and didn't get a response here. |
Attempting to initiate a remote build results in the following:
error: you are not privileged to build derivations
(nix (Nix) 2.2.2)Adding the remote user to the remote machine's
nix.conf
trusted-users
allows the build to continue as normal. This seems to be intended behaviour, but I had a few problems with it:nix.trustedUsers
, but it wasn't clear whether it was referring to the local (like when needed for use with--builders
) or the remote machine.remote builds require a trusted user
might be more obvious?nix copy --to ssh://builder /nix/store/whatever.drv && ssh builder nix build /nix/store/whatever.drv && nix copy --no-check-sigs --from ssh://builder /nix/store/whatever
works fine, so I was confused why remote builds with--builder
and nix.confbuilders
weren't able to do the same.I understood there would be drawbacks to setting it up this way (not trusting the remote user will prevent them from supplying binary substitutes for example, and with multiple builders could even result in duplicated work if the build scheduler isn't aware), but did not expect or find mention that it would be disallowed and prevented entirely. Is there a reason why this check exists? Attempting to send an unsigned build input to the remote machine would've already failed out the build before hitting this wopBuildDerivation error, so it's not immediately clear to me why this particular operation is gated to trusted users to begin with? Sorry if I'm misunderstanding what a "build derivation" operation actually is/does.
The text was updated successfully, but these errors were encountered: