In 14f09e0, I've introduced the module under modules/programs, because
the legacy virtualbox.nix was also under that path. But because we
already have modules/virtualisation/virtualbox-guest.nix, it really
makes sense to put this module alongside of it as well.
This module thus has no change in functionality and I've tested
evaluation against nixos/tests/virtualbox.nix and the manual.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
My original reason to put it at the beginning of NIX_PATH was to allow
shipping a particular version <nixpkgs> with a channel. But in order to
do that, we can still let the channel expression ship with a custom
version of nixpkgs by something like <channel/nixpkgs> and the builder
of the channel could also rewrite self-references.
So the inconvenience is now shifted towards the maintainer of the
channel rather than the user (which isn't nice, but better err on the
side of the developer rather than on the user), because as @edolstra
pointed out: Having the channels of root at the beginning of NIX_PATH
could have unintended side-effects if there a channel called nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is very useful if you want to distribute channels (and thus
expressions as well) in a similar fashion to Debians APT sources (or
PPAs or whatnot).
So, for example if you have a channel with some additional functions
or packages, you simply add that channel with:
sudo nix-channel --add https://example.com/my-nifty-channel foo
And you can access that channel using <foo>, for example in your
configuration.nix:
{
imports = [ <foo/modules/shiny-little-module> ];
environment.systemPackages = with import <foo/pkgs> {}; [ bar blah ];
services.udev.extraRules = import <foo/lib/udev/mkrule.nix> {
kernel = "eth*";
attr.address = "00:1D:60:B9:6D:4F";
name = "my_fast_network_card";
};
}
Within nixpkgs, we shouldn't have <nixos> used anywhere anymore, so we
shouldn't get into conflicts.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
By making askPassword an option, desktop environment modules can
override the default x11_ssh_askpassword with their own equivalent for
better integration. For example, KDE 5 uses plasma5.ksshaskpass instead.
This was lost back in
ffedee6ed5. Getting this to work is
slightly tricky because ssh-agent runs as a user unit, and so doesn't
know the user's $DISPLAY.
This reverts commit 766207ca1d.
We need to solve the problem with `environment.profileRelativeEnvVars`.
The best workaround is to make profileRelativeEnvVars prepend paths.
This reverts commit 5d67b17901.
The issues have been resolved by ac603e208c.
Tested this with hostonlyifs and USB support with extension pack.
Conflicts:
nixos/modules/programs/virtualbox-host.nix
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Tested-by: Mateusz Kowalczyk <fuuzetsu@fuuzetsu.co.uk>
IMHO, having a short timeout (1h) defeats the point of using
ssh-agent, which is not to have to retype passphrases all the time. Of
course, users who want timeouts can set programs.ssh.agentTimeout.
This restores the 14.04 behaviour.
Because we have to rely on setuid wrappers on NixOS, we can't easily
hardcode the executable paths and set it 4755. So for all calls, we need
to change the runtime path executable directory to /var/setuid-wrappers/
and for verification we need to retain the executable directory.
Also note, that usually VBoxNetAdpCtl, VBoxNetDHCP, VBoxNetNAT, VBoxSDL
and VBoxVolInfo don't reside in directories that are commonly in PATH,
but in /usr/lib/virtualbox in most mainstream distros. But because the
names of these executables are distinctive enough to not cause
collisions with other setuid programs, I'll leave it like that and not
patch up setuid-wrappers.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The warning was displayed whenever services.virtualboxHost.enable was
true, but if people were to enable hardening, they'd still get that
annoying message.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Creates unnecessary cruft in the root users home directory, which we
really don't need. Except the log, but therefore we now cat the log to
stderr and the private temporary directory is cleaned up afterwards.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should display a big fat warning that people can hardly miss until
we have fixed the issues with the host-only-interfaces that persist when
hardining is enabled.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Hardening mode in VirtualBox is quite restrictive and on some systems it
could make sense to disable hardening mode, especially while we still
have issues with hostonly networking and other issues[TM] we don't know
or haven't tested yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We only need to have setuid-root wrappers for VBox{Headless,SDL} and
VirtualBox, otherwise VBoxManage will run as root and NOT drop
privileges!
Fixes#5283.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The current nixos module for VirtualBox unconditionally configures a vboxnet0
network interface at boot. This may be undesired, especially when the user wants
to manage network interfaces in a centralized manner.
VirtualBox with hardening support requires the main binaries to be
setuid root. Using VBOX_WITH_RUNPATH, we ensure that the RPATHs are
pointing to the libexec directory and we also need to unset
VBOX_WITH_ORIGIN to make sure that the build system is actually setting
those RPATHs.
The hardened.patch implements two things:
* Set the binary directory to the setuid-wrappers dir so that
VboxSVC calls them instead of the binaries from the store path. The
reason behind this is because nothing in the Nix store can have the
setuid flag.
* Excempt /nix/store from the group permission check, because while it
is group-writeable indeed it also has the sticky bit set (and also
the whole store is mounted read-only on most NixOS systems), so we're
checking on that as well.
Right now, the hardened.patch uses /nix/store and /var/setuid-wrappers
directly, so someone would ever want to change those on a NixOS system,
please provide a patch to set those paths on build time. However, for
simplicity, it's best to do it when we _really_ need it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We will simply rename the previous module and add a warning whenever the
module is included directly, pointing the user to the right option and
also enable it as well (in case somebody has missed the option and is
wondering why VirtualBox doesn't work anymore).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
