[RFC 0008] Readonly recursive Nix

[shlevy]

Rendered: https://github.com/shlevy/rfcs/blob/readonly-recursive-nix/rfcs/0008-readonly-recursive-nix.md

[shlevy]

@edolstra

[edolstra]

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.

[shlevy]

All processes in the build share the same socket FD they use to request a new connection, those requests could beinterleaved.

[edolstra]

The idea seems mostly fine. A few comments:

• The main objection is that it significantly increases the attack surface from Nix builds, since they can now talk to a root process outside of the sandbox.

• Regarding daemon availability: A simpler approach would be to move all the daemon code from src/nix-daemon to libstore as a Daemon class that can be instantiated by DerivationGoal. So we just fire off a thread to handle incoming connections from the build. This also makes it easy to pass the StoreViewStore to the daemon (Daemon would just take a Store as a constructor argument).

• I don't see why FdDaemonStore is needed. Wouldn't the regular RemoteStore work? The only thing needed is a way to set the socket path (at least for non-sandbox builds where we can't create /nix/var/nix/daemon-socket/socket).

• I don't understand the name "StoreViewStore". Maybe RestrictedStore?

[shlevy]

@edolstra thanks for taking a look!

The main objection is that it significantly increases the attack surface from Nix builds, since they can now talk to a root process outside of the sandbox.

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)

Regarding daemon availability: A simpler approach would be to move all the daemon code from src/nix-daemon to libstore as a Daemon class that can be instantiated by DerivationGoal. So we just fire off a thread to handle incoming connections from the build. This also makes it easy to pass the StoreViewStore to the daemon (Daemon would just take a Store as a constructor argument).

Sure, makes sense.

I don't see why FdDaemonStore is needed. Wouldn't the regular RemoteStore work? The only thing needed is a way to set the socket path (at least for non-sandbox builds where we can't create /nix/var/nix/daemon-socket/socket).

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.

I don't understand the name "StoreViewStore". Maybe RestrictedStore?

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.

[joachifm]

and the counterpoint that the daemon is already meant to be accessible to everyone in a normal setup

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.

[edolstra]

Right. Currently sandboxed builds don't have access to the daemon socket.

[shlevy]

Right, it's not a complete counterpoint, just that the daemon already should be pretty secure.

[shlevy]

We could put this behind an off-by-default option.

[Ericson2314]

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.

[shlevy]

@edolstra @Ericson2314 Updated in response to your comments.

[Ericson2314]

@shlevy I'll respond in detail later when I'm not on my phone, but I think all those IFD drawbacks are very surmountable.

[shlevy]

@edolstra can we expect a response either way from you here?

[edolstra]

This looks good to me, thanks!

[shlevy]

@edolstra Awesome! 🎊

@zimbatm So what's the next step from the perspective of the RFC process?

[Ericson2314]

@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.

[0xABAB]

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.

[zimbatm]

@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?

[shlevy]

@zimbatm good call, will do when I get a chance