| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The problem is that when we kill the client while the worker is
building, and the builder is not writing anything to stderr, then
the worker never notice that the socket is closed on the other side,
so it just continues indefinitely. The solution is to catch SIGIO,
which is sent when the far side of the socket closes, and simulate
an normal interruption. Of course, SIGIO is also sent every time
the client sends data over the socket, so we only enable the signal
handler when we're not expecting any data...
|
|
|
|
|
|
|
|
client.
|
|
from interfering.
|
|
syncWithGC() to allow clients to register GC roots without needing
write access to the global roots directory or the GC lock.
|
|
|
|
* Much simpler setuid code for the worker in slave mode.
|
|
|
|
* Help for nix-worker.
|
|
|
|
* addToStore now adds unconditionally, it doesn't use readOnlyMode.
Read-only operation is up to the caller (who can call
computeStorePathForPath).
|
|
|
|
* addToStore() and friends: don't do a round-trip to the worker if
we're only interested in the path (i.e., in read-only mode).
|
|
* Added new operation hasSubstitutes(), which is more efficient than
querySubstitutes().size() > 0.
|
|
|
|
|
|
|
|
mode. Presumably nix-worker would be setuid to the Nix store user.
The worker performs all operations on the Nix store and database, so
the caller can be completely unprivileged.
This is already much more secure than the old setuid scheme, since
the worker doesn't need to do Nix expression evaluation and so on.
Most importantly, this means that it doesn't need to access any user
files, with all resulting security risks; it only performs pure
store operations.
Once this works, it is easy to move to a daemon model that forks off
a worker for connections established through a Unix domain socket.
That would be even more secure.
|
|
* Some refactoring: put the NAR archive integer/string serialisation
code in a separate file so it can be reused by the worker protocol
implementation.
|
|
|
|
|
|
|
|
containing functions that operate on the Nix store. One
implementation is LocalStore, which operates on the Nix store
directly. The next step, to enable secure multi-user Nix, is to
create a different implementation RemoteStore that talks to a
privileged daemon process that uses LocalStore to perform the actual
operations.
|
|
|
|
|
|
Rather, setuid support is now always compiled in (at least on
platforms that have the setresuid system call, e.g., Linux and
FreeBSD), but it must enabled by chowning/chmodding the Nix
binaries.
|
|
(NIX-70)
|
|
|
|
gives a huge speedup in operations that read or write from standard
input/output. (So libstdc++'s I/O isn't that bad, you just have to
call std::ios::sync_with_stdio(false).) For instance, `nix-store
--register-substitutes' went from 1.4 seconds to 0.1 seconds on a
certain input. Another victory for Valgrind.
|
|
now that reference scanning is sufficiently streamy.
|
|
graph to be passed to a builder. This attribute should be a list of
pairs [name1 path1 name2 path2 ...]. The references graph of each
`pathN' will be stored in a text file `nameN' in the temporary build
directory. The text files have the format used by `nix-store
--register-validity'. However, the deriver fields are left empty.
`exportReferencesGraph' is useful for builders that want to do
something with the closure of a store path. Examples: the builders
that make initrds and ISO images for NixOS.
`exportReferencesGraph' is entirely pure. It's necessary because
otherwise the only way for a builder to get this information would
be to call `nix-store' directly, which is not allowed (though
unfortunately possible).
|
|
this in the NixOS installer (or in the buildfarm) to ensure that the
cryptographic hash of the path contents still matches the actual
contents.
|
|
|
|
|
|
available. For instance,
$ nix-store -l $(which svn) | less
lets you read the build log of the Subversion instance in your
profile.
* `nix-store -qb': if applied to a non-derivation, take the deriver.
|
|
|
|
|
|
|
|
check that the references of the output of a derivation are in the
specified set. For instance,
allowedReferences = [];
specifies that the output cannot have any references. (This is
useful, for instance, for the generation of bootstrap binaries for
stdenv-linux, which must not have any references for purity). It
could also be used to guard against undesired runtime dependencies,
e.g.,
{gcc, dynlib}: derivation {
...
allowedReferences = [dynlib];
}
says that the output can refer to the path of `dynlib' but not
`gcc'. A `forbiddedReferences' attribute would be more useful for
this, though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
non-store paths to a builder.
|
