This mitigates CVE-2023-4911, crucially without a mass-rebuild.
We drop insecure environment variables explicitly, including
glibc-specific ones, since musl doesn't do this by default.
Change-Id: I591a817e6d4575243937d9ccab51c23a96bed6f9
A further bug to our strange multi-user.target depending on
network-online.target issue is that systemd recently changed the
behaviour of systemd-networkd-wait-online to no longer consider the
absence of interfaces with RequiredForOnline to be sufficient to be
online: https://github.com/systemd/systemd/pull/27825
On the advice of the systemd developers
(https://github.com/systemd/systemd/issues/29388), this commit changes
the configuration of systemd-networkd-wait-online to pass --any by
default, and lets the default DHCP interfaces be RequiredForOnline
as they would be by default if the option is omitted.
It is plausible that systemd-networkd-wait-online may still fail if
there are no interfaces at all. However, that probably cannot be
avoided.
systemd.network(5) describes Domains= as a "list of domains which should
be resolved using the DNS servers on this link." This setting is read by
systemd-resolved.service, and it's used to configure both search domains
and DNS query routing.
Adding the search domains from `networking.search` is unnecessary
because these are already configured globally in `resolved.conf` through
the default value of `services.resolved.domains`.
Adding the system's `networking.domain` to each network is unexpected
and probably incorrect. A user may not expect that the domain is in
effect automatically added to the search domains even if not specified
in `networking.search`.
Both of these network-level assignments are problematic in cases where
the NixOS networkd module is not managing every interface on the system.
In that scenario, the managed interfaces will have Domains= set while
the others do not. That will cause systemd-resolved to route DNS queries
for the search domains and the system domain to only those managed
interfaces.
Otherwise, in non-interactive contexts (e.g. systemd units), this
entry (the default) won't be in the list. Only the profile relative
ones would be, since they were already using session variables. This
is clearly not the correct behavior.
All the locate versions we have support LOCATE_PATH, so just use that
instead of adding indirections all over the place AND forcing people
to rebuild their locate implementation if they want the path changed.
Allow the user to disable overriding the fileSystems option with
virtualisation.fileSystems by setting
`virtualisation.fileSystems = lib.mkForce { };`.
With this change you can use the qemu-vm module to boot from an external
image that was not produced by the qemu-vm module itself. The user can
now re-use the modularly set fileSystems option instead of having to
reproduce it in virtualisation.fileSystems.
Gonic accesses external services (e.g. Listenbrainz or last.FM) for
scrobbling, but it was previously not allowed to read
`/etc/resolv.conf`.
This had the effect that, unless a local resolver was configured on
the system, any connection attempt would fail due to DNS resolution
being unavailable.
* `sort (<)` also works for strings (TIL!), so no need for comparing
length and whether all keys from `cfg.settings` exist in `cfg.order`
(slightly less overhead).
* Don't build another piece of JSON (`orderedSections`), simply use
`cfg.settings`/`cfg.order` with `__structuredAttrs` to ensure a
properly ordered TOML.
This also has the upside of not having to do quote hackery.
* Also, a freeform submodule isn't strictly needed because we don't have
any special options defined, so replacing that with
`attrsOf format.type`.
Co-authored-by: Silvan Mosberger <github@infinisil.com>
and remove nano from environment.defaultPackages. In addition also cleanup the file in general.
This is a follow up to #220481
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
Adds an option to configure a custom WakeOnLan policy instead of the
hard-coded "magic" policy. To ensure compatibility with current
behavior, "magic" is kept as default.
When using e.g. `{ addr = "[::]"; port = 22; }` at `listenAddresses`,
the check fails because of an escaping issue[1] with
last 1 log lines:
> Invalid test mode specification -f
For full logs, run 'nix log /nix/store/c6pbpw5hjkjgipmarwyic9zyqr1xaix5-check-sshd-config.drv'
Using `lib.escapeShellArg` appears to solve the problem.
[1] https://github.com/NixOS/nixpkgs/pull/256090#issuecomment-1738063528
Prior to this commit the derivation assumed a user's primary group has
the same name as the user themselves. This is standard on linux but not
necessary (and indeed I believe not the default on NixOS).
Closes#232184
PR#256295 reintroduced ruleFile option, but set the default as a path
literal, which was a "string path" previously. This breaks evaluation
for being impure:
error: access to absolute path '/var/lib/usbguard/rules.conf' is forbidden in pure eval mode (use '--impure' to override)
Rather than using `priority` with `sortProperties`, a new option called
`order` defines the ordering of the sections. I.e.
order = [ "global" "uptime" "banner" ]
means that `uptime` comes before `banner`. Please note that `global` is
for global settings and not a section. I figured that it'd be too much
magic to hide this in the implementation and ask the user to specify the
order of _each_ section in `settings` instead.
OTOH this makes the intent way clearer than priorities. Also, this
remains opt-in, the option defaults to `attrNames cfg.settings`, i.e.
all sections ordered alphabetically.
The text was originally added [0] following an apparently incomplete
research on how everything plays together. In fact, Nix propagates
`outputs` to the corresponding nested derivations, and there is some
messy behavior in Nixpkgs that only seems to propagate
`meta.outputsToInstall` in `buildEnv`[1].
This change moves the hints on how to use NixOS specifics to NixOS
module documentation (which is hopefully easier to find through
search.nixos.org), describes the default behavior in Nixpkgs (updating
a the link to the source), and removes the confusing mention of
`nix-env`.
the last of them should not be there to begin with. we don't want
beginners to use `nix-env`, as this is known to run them into trouble
eventually.
[0]: https://github.com/NixOS/nixpkgs/pull/76794
[1]: 1774d07242/pkgs/build-support/buildenv/default.nix (L66)
