Skip to content
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 0068] Minimal daemon #68

Closed
wants to merge 11 commits into from
70 changes: 70 additions & 0 deletions rfcs/0000-minimal-daemon.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
---
feature: minimal-daemon
start-date: 2020-5-28
author: John Ericson
co-authors: (find a buddy later to help out with the RFC)
shepherd-team: Eelco Dolstra, Théophane Hufschmitt, Finn Behrens
shepherd-leader: Eelco Dolstra
related-issues: (will contain links to implementation PRs)
---

# Summary
[summary]: #summary

`nix-daemon` should be a separate executable.

# Motivation
[motivation]: #motivation

With flakes and other development, we are moving towards a more "batteries included" Nix command line.
We don't want any of those features in the daemon, however, because the daemon is a special trusted process that we should strive to keep as simple as possible.
\[This is comparable to a compilation pipeline, with a concise intermediate representation that nicer user-facing features "desugar" into.\]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would either remove the square brackets, or remove this.


There are many things we could do about this, but I mainly want to establish some rough consensus around the problem while taking a small step to signal that consensus.
Originally, each Nix command was its own executable, but then we combined them into one executable.
Ericson2314 marked this conversation as resolved.
Show resolved Hide resolved
I think this is fine for the main user-facing commands, but not good for the daemon.

Finally, it's probably best not to give the daemon---a long lived process running with elevated privileges---access to tons of dead code.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we specify exactly what privileges the daemon is running with, here? I think it's pertinent to the motivations of this RFC.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And what is meant here by dead code?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will explain the "dead code". The elevated privileges thing I am not sure what to right: in theory the nix daemon just needs to be make sandboxes and access the store, but in practice we run it as root last I checked.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is run as Root. Currently the source doesn't allow anything else. We could check for CAPs, but we only check for Root prior to remounting the store in rw

All of the other commands entry points and library functions they use, such as the Nix evaluator, are in the same process even though the daemon should never need to use them.
C++ doesn't exactly prevent memory errors, and that dead code is just more fodder to be used in some low-level attack.
There are other solutions to this in the long term, but this is the easiest solution in the short term.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to mention the other solutions in Future Work, methinks.


# Detailed design
[design]: #detailed-design

- `nix-daemon` will be a separate executable that only links the nix libraries it needs.
\[At this time, those libraries are `libnixutil`, `libnixstore`, and `libnixrust`, but this is subject to change.\]

- `nix-daemon` should never need to understand the expression language and depend `libnixexpr`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 since the separate nix-daemon is also what allows things like guix

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean it allows guix?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the sense the daemon can work in other frameworks not directly related to Nix language. Guix can use the same daemon as us and they don't need to read a single line of Nix code, only Scheme (and maybe C++).


# Examples and Interactions
[examples-and-interactions]: #examples-and-interactions

I certainly hope there are no interactions!
One of the bad things we should seek to prevent with this is the daemon unintentionally growing dependencies on more of the code base.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be moved to the Motivations section.


# Drawbacks
[drawbacks]: #drawbacks

Installation is slightly bigger as the two binaries (`nix` and `nix-daemon`) have some redundancy.
Build rules perhaps are slightly more complex as there are both separate and independent executables.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would it take to remove the perhaps and know for sure? :)


# Alternatives
[alternatives]: #alternatives

- Do nothing.

- Something more invasive, such as packaging the libraries and commands separately, or intending the libaries for widespread public consumption.
But I much rather save that for later, as such steps would be far more controversial.

# Unresolved questions
[unresolved]: #unresolved-questions

No known unknowns.

# Future work
[future]: #future-work

I think most people for this will have future plans they wish to persue in the name of modularity.
But I don't expect everyone to agree on waht exactl those plans should be.
Ericson2314 marked this conversation as resolved.
Show resolved Hide resolved
The point of this small step is to punt on all that for now.