-
-
Notifications
You must be signed in to change notification settings - Fork 159
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
[RFC 0008] Readonly recursive Nix #8
Conversation
aa4c91f
to
bb53272
Compare
bb53272
to
781648e
Compare
rfcs/0008-readonly-recursive-nix.md
Outdated
Multiple processes in the build may be trying to open connections in | ||
parallel, but as long as each only consumes one response it doesn't | ||
matter if the response is the exact one corresponding to the specific | ||
request made. |
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.
I don't understand what this means. It seems to say there is some sort of race with multiple connections but I don't see how.
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.
All processes in the build share the same socket FD they use to request a new connection, those requests could beinterleaved.
The idea seems mostly fine. A few comments:
|
@edolstra thanks for taking a look!
True, I'll include that with the next draft (and the counterpoint that the daemon is already meant to be accessible to everyone in a normal setup)
Sure, makes sense.
Inheriting a file descriptor is just an alternative to specifying the socket path.I slightly prefer the former, but not strongly, I'll change this to do it that way instead if you prefer.
Yeah, that's btter. Though the more I think about it the more it seems like this is more a parameter of the daemon than an actual standalone store implementation anyway. |
If I understand correctly, the concern is not necessarily other local users but that the proposal increases the feasibility of attacking the host by injecting malicious code into the build process. |
Right. Currently sandboxed builds don't have access to the daemon socket. |
Right, it's not a complete counterpoint, just that the daemon already should be pretty secure. |
We could put this behind an off-by-default option. |
I'd like to see some of the comparison with import-from-derivation fleshed out. For example, I'm missing why this is more expressive. |
@edolstra @Ericson2314 Updated in response to your comments. |
@shlevy I'll respond in detail later when I'm not on my phone, but I think all those IFD drawbacks are very surmountable. |
@edolstra can we expect a response either way from you here? |
This looks good to me, thanks! |
@edolstra, would you also be OK in an RFC for improving import-from-derivation? They are in many cases competing ways to achieve the same thing, but implementation-wise there is no conflict. |
I think the RFC document (the one in the first message) is so vague that I have no idea what problems it intends to solve. Just based on that, I am already against. |
@shlevy the RFC is very dry right now. @edolstra and you can understand it because you have a lot of shared context on the nix implementation. To help the user's perspective, would you mind adding an example of nix code that would use the feature and then describe the various steps that the runtime would take when invoking the code? |
@zimbatm good call, will do when I get a chance |
Shorten the paths, rename to package.nix
Rendered: https://github.com/shlevy/rfcs/blob/readonly-recursive-nix/rfcs/0008-readonly-recursive-nix.md