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

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy
Member

shlevy commented Apr 2, 2017

@edolstra

This comment has been minimized.

Show comment
Hide comment
@edolstra

edolstra Apr 3, 2017

Member

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?

Member

edolstra commented Apr 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 3, 2017

Member

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

Member

shlevy commented Apr 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@joachifm

joachifm Apr 3, 2017

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.

joachifm commented Apr 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@edolstra

edolstra Apr 3, 2017

Member

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

Member

edolstra commented Apr 3, 2017

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

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 3, 2017

Member

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

Member

shlevy commented Apr 3, 2017

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

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 3, 2017

Member

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

Member

shlevy commented Apr 3, 2017

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

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Apr 4, 2017

Member

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.

Member

Ericson2314 commented Apr 4, 2017

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.

@zimbatm zimbatm changed the title from Add readonly-recursive-nix RFC to [RFC 008] Add readonly-recursive-nix RFC Apr 4, 2017

@edolstra edolstra changed the title from [RFC 008] Add readonly-recursive-nix RFC to [RFC 008] Readonly recursive Nix Apr 10, 2017

@zimbatm zimbatm changed the title from [RFC 008] Readonly recursive Nix to [RFC 0008] Readonly recursive Nix Apr 13, 2017

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 13, 2017

Member

@edolstra @Ericson2314 Updated in response to your comments.

Member

shlevy commented Apr 13, 2017

@edolstra @Ericson2314 Updated in response to your comments.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Apr 16, 2017

Member

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

Member

Ericson2314 commented Apr 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 27, 2017

Member

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

Member

shlevy commented Apr 27, 2017

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

@edolstra

This comment has been minimized.

Show comment
Hide comment
@edolstra

edolstra May 1, 2017

Member

This looks good to me, thanks!

Member

edolstra commented May 1, 2017

This looks good to me, thanks!

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy May 1, 2017

Member

@edolstra Awesome! 🎊

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

Member

shlevy commented May 1, 2017

@edolstra Awesome! 🎊

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

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 May 2, 2017

Member

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

Member

Ericson2314 commented May 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@0xABAB

0xABAB Jun 30, 2017

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.

0xABAB commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Jul 2, 2017

Member

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

Member

zimbatm commented Jul 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Jul 2, 2017

Member

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

Member

shlevy commented Jul 2, 2017

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

@shlevy shlevy closed this Jan 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment