at boot time into a separate script. This will allow us to change
the configuration without rebooting (provided that the configuration
doesn't have a different kernel, init, etc.).
svn path=/nixos/trunk/; revision=7294
except for the fonts, which are still hardcoded. The current
configuration uses the VESA driver, which should work on most
machines. Of course, the configuration should now be generated from
a higher-level specification.
svn path=/nixos/trunk/; revision=7165
program.
The Nix store cannot directly support setuid binaries for a number
of reasons:
- Builds are generally not performed as root (and they shouldn't
be), so the builder cannot chown/chmod executables to the right
setuid ownership.
- Unpacking a NAR archive containing a setuid binary would only work
when Nix is run as root.
- Worst of all, setuid binaries don't fit in the purely functional
model: if a security bug is discovered in a setuid binary, that
binary should be removed from the system to prevent users from
calling it. But we cannot garbage collect it unless all
references to it are gone, which might never happen. Of course,
we could just remove setuid permission, but that would also be
impure.
So the solution is to keep setuid-ness out of the Nix store.
Rather, for programs that we want to execute as setuid, we generate
wrapper programs (as root) that are setuid and do an execve() to
call the real, non-setuid program in the Nix store.
That's what setuid-wrapper does. It determines its own name (e.g.,
/var/setuid-wrappers/passwd), reads the name of the wrapped program
from <self>.real (e.g., /var/setuid-wrappers/passwd.real, which
might contain /nix/var/nix/profiles/system/bin/passwd), and executes
it. Thus, the non-setuid passwd in the Nix store would be executed
with the effective user set to root.
Setuid-wrapper also performs a few security checks to prevent it
from reading a fake <self>.real file through hard-linking tricks.
svn path=/nixos/trunk/; revision=7157
of NixOS to be specified externally from the main Nix expressions
(since an installation would be hard to maintain if users started
editing the NixOS expressions directory). But to make that
user-friendly we need:
- Hierarchical options (just like the Nixpkgs configuration).
- Option descriptions from which documentation can be generated.
- Validation (e.g., does each option exist? does it have a valid
value?).
- The option declarations should be inside the Nix expressions to
which they are relevant (rather than, say, one big file with option
declarations).
svn path=/nixu/trunk/; revision=7148
by the program /sbin/splash_helper in the initrd and is called even
before /init.
* make-initrd.nix: allow a list of FSOs to be placed in the initrd,
with a symlink to each top-level FSO (e.g., /init,
/sbin/splash_helper, /etc/splash).
* make-initrd.nix: pre-create /proc, /dev and /sys, because
splash_helper needs them.
svn path=/nixu/trunk/; revision=7144
