Until now, the `touch + chmod 600 + write` approach made it possible for
an unprivileged local user read the private key file, by opening
the file after the touch, before the read permissions are restricted.
This was only the case if `generatePrivateKeyFile = true` and the parent
directory of `privateKeyFile` already existed and was readable.
This commit fixes it by using `umask`, which ensures kernel-side that
the `touch` creates the file with the correct permissions atomically.
This commit also:
* Removes `mkdir --mode 0644 -p "${dirOf values.privateKeyFile}"`
because setting permissions `drw-r--r--` ("nobody can enter that dir")
is awkward. `drwx------` would perhaps make sense, like for `.ssh`.
However, setting the permissions on the private key file is enough,
and likely better, because `privateKeyFile` is about that file
specifically and no docs suggest that there's something special
about its parent dir.
* Removes the `chmod 0400 "${values.privateKeyFile}"`
because there isn't really a point in removing write access from
the owner of the private key.
- Set an explicit umask that allows u+rwx and g+r.
- Adds `ProtectControlGroups` and `ProtectKernelLogs`, there should be
no need to access either.
- Adds `ProtectClock` to prevent write-access to the system clock.
- `ProtectProc` hides processes from other users within the /proc
filesystem and `ProcSubSet` hides all files/directories unrelated to
the process management of the units process.
- Sets `RemoveIPC`, as there is no SysV or POSIX IPC within nginx that I
know of.
- Restricts the creation of arbitrary namespaces
- Adds a reasonable `SystemCallFilter` preventing calls to @privileged,
@obsolete and others.
And finally applies some sorting based on the order these options appear
in systemd.exec(5).
See #119615 for more details. The aarch64-linux test failed with
"qemu-system-aarch64: Virtio VGA not available" so I've restricted the
test to x86_64-linux (the virtio paravirtualized 3D graphics driver is
likely only available on very few platforms).
The result still looks far from ideal but at least it gets recognized
now. "-fa Monospace" is required to switch to a font from the FreeType
library so that "-fs 24" works.
Note: Using linuxPackages_latest is not required anymore.
On reboots and shutdowns promtail blocks for at least 90 seconds,
because it would still try to deliver log messages for loki, which isn't
possible when the network has already gone down.
Upstreams example unit also uses a ten seconds timeout, something which
has worked pretty well for me as well.
systemd-nspawn can react to SIGTERM and send a shutdown signal to the container
init process. use that instead of going through dbus and machined to request
nspawn sending the signal, since during host shutdown machined or dbus may have
gone away by the point a container unit is stopped.
to solve the issue that a container that is still starting cannot be stopped
cleanly we must also handle this signal in containerInit/stage-2.
This reverts commit d6e0d38b84.
We need shorter secrets to continue working, since the earlier
recommendation was too short and there's no way to rotate the them.
The upstream recommended minimum length for db_key_base is 30 bytes,
which our option descriptions repeated. Recently, however, upstream
has, in many places, moved to using aes-256-gcm, which requires a key
of exactly 32 bytes. To allow for shorter keys, the upstream code pads
the key in some places. However, in many others, it just truncates the
key if it's too long, leaving it too short if it was to begin
with. This adds a patch that fixes this and updates the descriptions
to recommend a key of at least 32 characters.
See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53602
This version contains a vulnerability[1], and isn't maintained. The
original reason to have two jellyfin versions was to allow end-users to
backup the database before the layout was upgraded, but these backups
should be done periodically.
[1]: <https://nvd.nist.gov/vuln/detail/CVE-2021-21402>
Work around missing /dev files inside runInLinuxVM by creating a
symlink before calling nixos-enter.
This fixes https://github.com/NixOS/nixpkgs/issues/93381.
I ran into this issue when trying to create a VMware image that boots from EFI.
Thanks @colemickens for reporting this and @danielfullmer for fixing the same thing in in qemu-vm.nix (37676e77cb) and explaining what the issue was.
This ensures the following gptfdisk warning won't happen:
```
Warning: File size is not a multiple of 512 bytes! Misbehavior is likely!
```
Additionally, helps towards aligning the partition to be more optimal
for the underlying storage.
It is actually impossible to align for the actual underlying storage
optimally because we don't know what the block device will be!
But aligning on 1MiB should help.
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
The last bits to prevent babeld from running unprivileged was its
kernel_setup_interface routine, that wants to set per interface
rp_filter. This behaviour has been disabled in a patch that has been
submitted upstream at https://github.com/jech/babeld/pull/68 and reuses
the skip-kernel-setup config option.
→ Overall exposure level for babeld.service: 1.7 OK 🙂
This is a bit of a thorny issue. See, the actual `diskSize` variable is
for the *total* disk size, not for the filesystem!
The automatic numbers are meant to compute the *filesystem* required
space. So we have to add any other reserved space!
We have different requirements for reserved space. E.g. there could be
none (when it's actually a filesystem image). There could also be 1MiB
for alignment for an MBR image, legacy+gpt needs 2MiB, then GPT with an
ESP ("bootSize") needs to take the boot partition and GPT size into
account too!
Though luckily(?) for this latter situation we can cheat! As noted in the
change, `bootSize` is NOT the boot partition size. It is actually the
offset where the target filesystem starts.
Reserved space includes:
- inodes space in use (2 blocks per)
- about 5.2% of the space
The 5.2% reserved space was computed empirically when working on a
previous EXT4 image builder. It seems to stabilize around 5% even for
much larger filesystems.
On some filesystems, `du` without `--apparent-size` will not give the
actual size for a file. Using `--apparent-size` will give us the actual
file size.
Though, this is not actually correct still. 1000 × 1 bytes is not 1000
bytes. It is 1000 × ceil(filesize/blockSize)*blockSize.
So instead of adding up the actual file sizes. We are adding up the
block sizes.
Note that this also changes the builder to work with *bytes*, rather
than with any other units. Doing maths on bytes is less likely to go
awry than doing it on other units.
some ban actions need additional packages (eg ipset). since actions can be
provided by the user we need something general that's easy to configure.
we could also enable ipset regardless of the actual configuration of the system
if the iptables firewall is in use (like sshguard does), but that seems very
clumsy and wouldn't easily solve the binary-not-found problems other actions may
also have.
it's not possible to set a different default maxretry value in the DEFAULT jail
because the module already does so. expose the maxretry option to the
configuration to remedy this. (we can't really remove it entirely because
fail2ban defaults to 5)
As a temporary workaround for #120473 while the image builder is patched
to correctly look up disk sizes, partially revert
f3aa040bcb for EC2 disk images only.
We retain the type allowing "auto" but set the default back to the
previous value.
When performing OCR, some of the Tesseract settings perform better than
others on a variety of different workloads, but they mostly take
~negligible incremental time to run compared to the overhead of running
the ImageMagick filters.
After this commit, we try using all three of the current Tesseract
models (classic, LSTM, and classic+LSTM) to generate output text. This
fixes chromium-90's tests at release-20.09, and should make cases where
you're looking for *specific* text better, with the tradeoff of running
Tesseract multiple times.
To make it sensible to cherrypick this into release-20.09, this doesn't
change the existing API surface for the test driver. In particular,
get_screen_text continues to have the existing behaviour.
backends changing shouldn't be very likely, but services may well change. we
should restart sshguard from nixos-rebuild instead of merely plopping down a new
config file and waiting for the user to restart sshguard.
Rather than relying on carefully avoiding touching the 9P-mounted
/nix/store, we instead install a small NixOS system, similar to
the installer tests, and boot from that.
This avoids the various pitfalls associated with trying to unsuspend
properly and trades off a bunch of boilerplate for what will hopefully
be a more reliable test.
Additionally, this test now actually tests booting the system using a
bootloader, rather than the previous method of just booting the kernel
directly.
There is no need for a separate unit. Simplify the NixOS module by adding the shell code to preStart of the main unit, where the other initialization code already is.
Things will get quite broken if an /etc/passwd entry contains a
colon (which terminates a field), or a newline (which terminates a
record). I know because I just accidentally made a user whose home
directory path contained a newline!
So let's make sure that can't happen.
The buildkite agent supports multiple tags with the same key. This
functionality is used to have a [single agent listen on multiple
queues](https://buildkite.com/docs/agent/v3/queues#setting-an-agents-queue).
However, having the tags be of type `attrsOf str` means that
we cannot suport this use case. This commit modifies the type
of tags to be `attrsOf (either str (listOf str))` where the list
is expanded into multiple tags with the same key.
Example:
```
{tags = {queue = ["default", "testing"];};}
```
generates
```
tags="queue=default,queue=testing"
```
in the buildkite agent configuration.
Upstream repositories do no longer exists. There has been no release in
a while. - Not a good combination for a network daemon running as root
in C that parses network packets...
A too low number of inotify user instances causes similar problems as
max_user_watches. Without this, my workstation keeps running into things
like this:
$ sudo systemctl restart display-manager.service
Failed to allocate directory watch: Too many open files
aa22be179a dropped the backend setting
which was used in the test, breaking evaluation of the test in the
process. Kind of defeats the purpose of a test if it isn't executed
before merging a change to a module…
Remove old CUDA toolkits (and corresponding CuDNN versions).
- Not supported by upstream anymore.
- We do not use them in nixpkgs.
- We do not test or actively maintain them.
- Anything but ancient GPUs is supported by newer toolkits.
Fixes #107131.
* nixos/nginx: add upstreams examples
I am not fully sure if they are fully correct but they deployed the right syntax.
* nixos/nginx: use literal example
* Update nixos/modules/services/web-servers/nginx/default.nix
* Update nixos/modules/services/web-servers/nginx/default.nix
Bash doesn't handle subshell errors properly if the result is used as
input to a command. To cause the services to fail when the files can't
be read, we need to assign the value to a variable, then export it
separately.
For a while now it's possible to specify an additional config file in
`wpa_supplicant`[1]. In contrast to the file specified via `-c` this was
supposed to be used for immutable settings and not e.g. additional
networks.
However I'm a little bit unhappy about the fact that one has to choose
between a fully imperative setup and a fully declarative one where the
one would have to write credentials for e.g. WPA2-enterprise networks
into the store.
The primary problem with the current state of `wpa_supplicant` is that
if the `SAVE_CONFIG` command is invoked (e.g. via `wpa_cli`), all known
networks will be written to `/etc/wpa_supplicant.conf` and thus all
declarative networks would get out of sync with the declarative
settings.
To work around this, I had to change the following things:
* The `networking.wireless`-module now uses `-I` for declarative config,
so the user-controlled mode can be used along with the
`networks`-option.
* I added an `ro`-field to the `ssid`-struct in the
`wpa_supplicant`-sources. This will be set to `1` for each network
specified in the config passed via `-I`.
Whenever config is written to the disk, those networks will be
skipped, so changes to declarative networks are only temporary.
[1] https://w1.fi/cgit/hostap/commit/wpa_supplicant?id=e6304cad47251e88d073553042f1ea7805a858d1
With the config suggested in the module docs both Mailman core and
Hyperkitty are running, but Mailman core can not connect to Hyperkitty,
since the default hyperkitty.baseUrl is not set up by the module.
This adds a http listener to the uwsgi config and changes the default
hyperkitty.baseUrl to connect to this http listener.
