thanks to unionfs. For instance, nix-env and nixos-rebuild work.
The tricky part was to build a Nix database (in the tmpfs/unionfs)
which is now necessary to prevent store paths on the CD from being
deleted right away because they otherwise wouldn't be valid.
* nixos-install: use the /etc/nixos/configuration.nix from the target
file system (don't copy it anymore). Since the user is supposed to
mount the target file system on /mnt anyway, we may as well require
that configuration.nix is placed in /mnt/etc/nixos. This also makes
upgrading / reinstalling much easier, since it will automatically
use the right configuration.nix.
svn path=/nixos/trunk/; revision=10399
appear writable (though all writes go to a tmpfs). This allows you
to run Nix operations on the Live CD. However, we're not quite
there yet since the CD doesn't have a valid Nix database. So for
instance a garbage collect will cause everything to be deleted,
hanging the system.
svn path=/nixos/trunk/; revision=10276
as regular files instead of symlinks to the store.
* Sudo configuration, enabled through security.sudo.enable (on by
default). The contents of the sudoers file is specified in
security.sudo.configFile. The default sudoers file allows members
of the new "wheel" group to run any command.
svn path=/nixos/trunk/; revision=9138
list of user accounts that the job needs to run. For instance, the
SSH daemon job says:
{ name = "sshd";
uid = (import ../system/ids.nix).uids.sshd;
description = "SSH privilege separation user";
home = "/var/empty";
}
The activation script creates the system users/groups and updates
them as well. So a change in the Nix expression can be realised in
/etc/{group,passwd} by running nixos-rebuild.
svn path=/nixos/trunk/; revision=8846
installation to prevent horrible accidents.
* Add the kernel parameters to isolinux.cfg.
* Use useradd/groupadd to create users/groups; use Glibc's getent to
check for existence.
* Create the root account properly.
svn path=/nixos/trunk/; revision=7357
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
