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.
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.
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.
