This allows for other unmanaged tables to co-exist peacefully on the os,
by having the nixos-managed tables be re-created atomically and the other
tables will simply be left untouched.
Given that we are no longer inspecting the target of the /proc/self/exe
symlink, stop asserting that it has any properties. Remove the plumbing
for wrappersDir, which is no longer used.
Asserting that the binary is located in the specific place is no longer
necessary, because we don't rely on that location being writable only by
privileged entities (we used to rely on that when assuming that
readlink(/proc/self/exe) will continue to point at us and when assuming
that the `.real` file can be trusted).
Assertions about lack of write bits on the file were
IMO meaningless since inception: ignoring the Linux's refusal to honor
S[UG]ID bits on files-writeable-by-others, if someone could have
modified the wrapper in a way that preserved the capability or S?ID
bits, they could just remove this check.
Assertions about effective UID were IMO just harmful: if we were
executed without elevation, the caller would expect the result that
would cause in a wrapperless distro: the targets gets executed without
elevation. Due to lack of elevation, that cannot be used to abuse
privileges that the elevation would give.
This change partially fixes#98863 for S[UG]ID wrappers. The issue for
capability wrappers remains.
/proc/self/exe is a "fake" symlink. When it's opened, it always opens
the actual file that was execve()d in this process, even if the file was
deleted or renamed; if the file is no longer accessible from the current
chroot/mount namespace it will at the very worst fail and never open the
wrong file. Thus, we can make a much simpler argument that we're reading
capabilities off the correct file after this change (and that argument
doesn't rely on things such as protected_hardlinks being enabled, or no
users being able to write to /run/wrappers, or the verification that the
path readlink returns starts with /run/wrappers/).
Before this change it was crucial that nonprivileged users are unable to
create hardlinks to SUID wrappers, lest they be able to provide a
different `.real` file alongside. That was ensured by not providing a
location writable to them in the /run/wrappers tmpfs, (unless
disabled) by the fs.protected_hardlinks=1 sysctl, and by the explicit
own-path check in the wrapper. After this change, ensuring
that property is no longer important, and the check is most likely
redundant.
The simplification of expectations of the wrapper will make it
easier to remove some of the assertions in the wrapper (which currently
cause the wrapper to fail in no_new_privs environments, instead of
executing the target with non-elevated privileges).
Note that wrappers had to be copied (not symlinked) into /run/wrappers
due to the SUID/capability bits, and they couldn't be hard/softlinks of
each other due to those bits potentially differing. Thus, this change
doesn't increase the amount of memory used by /run/wrappers.
This change removes part of the test that is obsoleted by the removal of
`.real` files.
This change includes some stuff (e.g. reading of the `.real` file,
execution of the wrapper's target) that belongs to the apparmor policy
of the wrapper. This necessitates making them distinct for each wrapper.
The main reason for this change is as a preparation for making each
wrapper be a distinct binary.
with a config like this :
```
services.tts = {
servers = {
english = {
enable = true;
port = 5300;
model = "tts_models/en/ljspeech/vits"
};
};
};
```
You the WAVs tts creates contain an error message which will be read to
you before the text you typed in will be read to you.
This patch fixes that.
dwm is not in Java's internal list of non-reparrenting
window managers. Running Java GUI programs without this
variable on window managers (eg. jd-gui) causes the window
to be blank.
Before this commit there was no way to access (boot into) specialisation of previous generations from grub,even tho they are there.
This commit will add grub submenu for each generation if the generation has any specialisation.
Which will allow you to boot into them.
Co-authored-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
We should sometimes restart the units rather than reloading them so the
changes are actually applied. / and /nix are explicitly excluded because
there was some very old issue where these were unmounted. I don't think
this will affect many people since most people use fstab mounts instead
but I plan to adapt this behavior for fstab mounts as well in the future
(once I wrote a test for the fstab thingies).
The next commit is going to add an option which takes a list of
packages. So the example must be converted to make it documentable.
This will also allow adding comments, to explain why some options are
used.
Given that we are no longer inspecting the target of the /proc/self/exe
symlink, stop asserting that it has any properties. Remove the plumbing
for wrappersDir, which is no longer used.
Asserting that the binary is located in the specific place is no longer
necessary, because we don't rely on that location being writable only by
privileged entities (we used to rely on that when assuming that
readlink(/proc/self/exe) will continue to point at us and when assuming
that the `.real` file can be trusted).
Assertions about lack of write bits on the file were
IMO meaningless since inception: ignoring the Linux's refusal to honor
S[UG]ID bits on files-writeable-by-others, if someone could have
modified the wrapper in a way that preserved the capability or S?ID
bits, they could just remove this check.
Assertions about effective UID were IMO just harmful: if we were
executed without elevation, the caller would expect the result that
would cause in a wrapperless distro: the targets gets executed without
elevation. Due to lack of elevation, that cannot be used to abuse
privileges that the elevation would give.
This change partially fixes#98863 for S[UG]ID wrappers. The issue for
capability wrappers remains.
/proc/self/exe is a "fake" symlink. When it's opened, it always opens
the actual file that was execve()d in this process, even if the file was
deleted or renamed; if the file is no longer accessible from the current
chroot/mount namespace it will at the very worst fail and never open the
wrong file. Thus, we can make a much simpler argument that we're reading
capabilities off the correct file after this change (and that argument
doesn't rely on things such as protected_hardlinks being enabled, or no
users being able to write to /run/wrappers, or the verification that the
path readlink returns starts with /run/wrappers/).
Before this change it was crucial that nonprivileged users are unable to
create hardlinks to SUID wrappers, lest they be able to provide a
different `.real` file alongside. That was ensured by not providing a
location writable to them in the /run/wrappers tmpfs, (unless
disabled) by the fs.protected_hardlinks=1 sysctl, and by the explicit
own-path check in the wrapper. After this change, ensuring
that property is no longer important, and the check is most likely
redundant.
The simplification of expectations of the wrapper will make it
easier to remove some of the assertions in the wrapper (which currently
cause the wrapper to fail in no_new_privs environments, instead of
executing the target with non-elevated privileges).
Note that wrappers had to be copied (not symlinked) into /run/wrappers
due to the SUID/capability bits, and they couldn't be hard/softlinks of
each other due to those bits potentially differing. Thus, this change
doesn't increase the amount of memory used by /run/wrappers.
We set[1] ASPELL_CONF to the last nix profile containing lib/aspell in
2013. In 2017, aspell is patched[2] to search NIX_PROFILES, which
makes [1] not needed any more.
Deleting it is also agreed in this discussion[3].
[1]: 0192c02720
[2]: ba4cefe4ae
[3]: https://github.com/NixOS/nixpkgs/pull/30234
exiftool is written in Perl which appears to call `chown` as part of startup. This is blocked by the `@privileged` system call group. This causes a failure when changing image orientation.
Fixes: https://github.com/NixOS/nixpkgs/issues/249120
remove `with lib;`
profiles option now accepts packages in addition to paths.
profiles option is no longer internal.
cfgDir definition has been inlined.
pulled GIO_EXTRA_MODULES inside mkif.
removed pointless comments with section headings.
defined profiles are now turned into package, allowing to simplify the db update logic.
This change also generates the invidious config by putting JSON
snippets into a bash array and then using jq to merge them all into
a single configuration where later elements override previous
elements.
- Move contents of README.md from
nixos/modules/installer/tools/manpages/ to
nixos/doc/manual/contributing-to-this-manual.chapter.md.
- Don't mention DocBook as its obsolete and too specific.
- Rename derivation attribute name of configuration.nix(5) manual page,
both on the `contributing-to-this-manual.chapter.md`, and in other
places.
Since each such `nixos-*` tool has it's own derivation, exposed in pkgs,
There is no point in separating the manuals from the packages. If
someone wishes to have the tools without the manuals, they can use
meta.outputsToInstall to disable the installation of the manpages of
these packages. This Fixes#244450.
adwaita-qt tries valiantly to ensure a visual consistency
but unfortunately, it often falls into an uncanny valley instead.
Let’s make it opt-in again for more vanilla default experience.
Related: https://pagure.io/fedora-workstation/issue/351
If other sockets are enabled, such as gpg-agent-browser.socket,
those should be started before gpg-agent.service as well.
Change-Id: I29d3f4b19db9e687425b594dcef863a88ec296c9
Since Linux 5.7 it's possible to set `SO_BINDTODEVICE` via `setsockopt(2)`
as unprivileged user if this operation doesn't imply escaping a VRF
interface[1].
Dropping the wrapper is actually desirable because `captive-browser`
itself doesn't drop capabilities and as a result, the capabilities are
passed on to `chromium` itself[2].
For older kernels, this is still necessary, hence the wrapper will only
be added nowadays if the kernel is older than 5.7.
[1] c427bfec18
[2] 08450562e5/bind_device_linux.go (L11-L14)
and because our setcap wrapper makes all capabilities
inheritable.
In user namespaces where an unprivileged user is mapped as root and root
is unmapped, setuid bits have no effect. However setuid root
executables like mount are still usable *in the namespace* as the user
already has the required privileges. This commit detects the situation
where the wrapper gained no privileges that the parent process did not
already have and in this case does less sanity checking. In short there
is no need to be picky since the parent already can execute the foo.real
executable themselves.
Details:
man 7 user_namespaces:
Set-user-ID and set-group-ID programs
When a process inside a user namespace executes a set-user-ID
(set-group-ID) program, the process's effective user (group) ID
inside the namespace is changed to whatever value is mapped for
the user (group) ID of the file. However, if either the user or
the group ID of the file has no mapping inside the namespace, the
set-user-ID (set-group-ID) bit is silently ignored: the new
program is executed, but the process's effective user (group) ID
is left unchanged. (This mirrors the semantics of executing a
set-user-ID or set-group-ID program that resides on a filesystem
that was mounted with the MS_NOSUID flag, as described in
mount(2).)
The effect of the setuid bit is that the real user id is preserved and
the effective and set user ids are changed to the owner of the wrapper.
We detect that no privilege was gained by checking that euid == suid
== ruid. In this case we stop checking that euid == owner of the
wrapper file.
As a reminder here are the values of euid, ruid, suid, stat.st_uid and
stat.st_mode & S_ISUID in various cases when running a setuid 42 executable as user 1000:
Normal case:
ruid=1000 euid=42 suid=42
setuid=2048, st_uid=42
nosuid mount:
ruid=1000 euid=1000 suid=1000
setuid=2048, st_uid=42
inside unshare -rm:
ruid=0 euid=0 suid=0
setuid=2048, st_uid=65534
inside unshare -rm, on a suid mount:
ruid=0 euid=0 suid=0
setuid=2048, st_uid=65534
Removing a network from the joinNetworks list does not make the machine leave the network which is confusing.
This behavior is now clarified via the options description
For non-interactive installation it's quite handy to be able to nix copy additional dependencies to the system.
While this is possible for the root user, we cannot easily ssh into it, as we don't allow root login with a password.
By making nixos a trusted user, we can do "passwd && sudo systemctl start sshd" and than run nixos-anywhere
This option only has an effect on the initial setup of Nextcloud and
changes later won't have any effect.
Same issue as with `adminpassFile` - it's only passed to the installer
command - but even worse because the username is frequently used as
unique ID in the database, so there's no trivial way to change it, even
imperatively.
Following a decicion from both the gitea and forgejo maintainers in
nixpkgs.
This means, that forgejo will no longer co-use the nixos/gitea module
via `services.gitea.package = pkgs.forgejo`.
As suggested by @nickcao this commit moves the defaults back to the
options. Only `homeserver.domain` stays in the config section since the
documentation module does not support referencing attributes of other
modules.
The upstream default for the thumbnail font is set to "Liberation Serif
Regular" located at /usr/share/fonts which is inaccessible under nix.
(2a2bf3bf55/src/paperless/settings.py (L894))
Paperless throws an error when parsing plaintext files without a valid
font. This change sets a nix default using the liberation_ttf package.
Netdata creates its control socket at /tmp/netdata-ipc by default, which
is insecure and actually inaccessible with systemd's PrivateTmp enabled.
Originally we patched its source code to move the socket to
/run/netdata/ipc. However, it was removed due to incompatibility when
upgrading to v1.41.0: 1d2a2dc7d0
Fortunately, this new version of netdata adds support for setting the
location of the control socket via the environment variable
NETDATA_PIPENAME. So let's set it for the netdata service and the
command line utility so that they can communicate properly.
Right now, the settings aren't additive which means that when I do
services.nextcloud.phpOptions."opcache.interned_strings_buffer = "23";
all other options are discarded because of how the module system works.
This isn't very nice in this case, though because wanting to override
a single option doesn't mean I want to discard the rest of the -
reasonable - defaults. Hence, the settings are showed as default in the
option's manual section, but are added with normal priority.
That means, to override _all_ options at once, an expression like
services.nextcloud.phpOptions = mkForce {
/* ... */
};
is needed. This is also way more intuitive IMHO because the `mkForce`
explicitly tells that everything will be modified.
Also, APCu enable and the memory & file-size limits are also written
into `services.nextcloud.phpOptions` rather than adding them
silently before passing all options to the PHP package. This has the
benefit that users will realize on evaluation time that they configured
options that would otherwise be set by the module on its own.
When I boot there's a warning `stage-2-init: install: cannot change permissions of '/etc/nixos': No such file or directory`
because my /etc/nixos is a symlink to $HOME/dotfiles.
```
/etc/nixos -> /home/artturin/dotfiles
```
These lines were added in 56b4653904
Allow giving a custom package containing the `systemd-repart` binary.
Defaults to `pkgs.systemd`. This option opens up the possibility to use
a different package for the image builder and the system configuration.
For example, someone could use this option to build an image with a
patched systemd while still using the upstream nixpkgs systemd package
(i.e., `pkgs.systemd`) for the system configuration installed to the
created image.
This avoids creating a build-time reference on `boot.kernelParams` if
the configuration does not use a kernel, i.e., `boot.kernel.enable` is
set to `false`.
Output the amended repart definitions to a well-known directory in
$TMPDIR instead of using a temporary directory with a random directory
name.
The output file `repart-output.json` also contains the full path to the
repart definition file used to create the partition. As
`amend-repart-definitions.py` uses `tempfile.mkdtemp`, this introduces
an impurity:
```json
{
"type" : "root-x86-64",
"label" : "rootfs",
"uuid" : "f2fa2e49-e443-45d2-a2e2-c3754cab6363",
"file" : "/build/tmppjo7kv5o/rootfs.conf",
"node" : "image.raw2",
"offset" : 135266304,
"old_size" : 0,
"raw_size" : 1651101696,
"old_padding" : 0,
"raw_padding" : 0,
"activity" : "create",
}
```
This commit changes the parent directory of the amended repart
definitions to `/build/amended-repart.d/`.
NOTES:
@jakeschurch did not realize that is was already updated on master, but not
backported to 23.05 channel
Signed-off-by: Jake Schurch <jakeschurch@gmail.com>
After building the target system, `nixos-install` tries to remove `/mnt`
on the target filesystem. And the script may fail without any explanation,
if `/mnt` isn't empty.
This commit makes the installation process carry on even if there are
files under `/mnt`.
See https://github.com/NixOS/nixpkgs/issues/244643.
There is only other `with` with a somewhat broad scope, `with pkgs`, but
it's used in a place where it would become awkward to change out. And
anyway its scope is rather limited still.
With a limited testing of all packaged GRUB 2 themes (pkgs.nixos-grub2-theme)
this is tested to work.
Without this change, the theme loading will error out (waiting for a key press).
With this change, the theme loads and works as expected.
The intent was to not pass the flag when installing as removable. In
reality there is a third case, where you may not want to touch EFI
variables, and not want to install as removable.
In that case, it would install to the generic \EFI\grub\grubx64.efi,
which is not a good choice in any cases. The operating system should
"own" their path under \EFI\ to be a good citizen [citation needed].
With this change, there can be only two paths GRUB can be installed to:
- \EFI\NixOS-boot\grubx64.efi
- \EFI\BOOT\bootx64.efi
This removes the surprising behaviour where GRUB may be installed to a
different location only because we configured NixOS not to touch EFI
variables.
It may be necessary under some configurations to install GRUB without
touching EFI variables, but to the NixOS-owned location.
Write the output of `systemd-repart` as a JSON file to
`$out/repart-output.json`.
Depending on the repart configuration, the output of `systemd-repart`
contains important information, for example, when creating verity
partitions:
> The verity root hash itself will be included in the output of
> systemd-repart.
See `Verity=` in repart.d(5).
https://github.com/kanidm/kanidm/releases/tag/v1.1.0-beta.13
The kanidmd process now creates a unix socket, over which admin tasks
can be done, without having to shut kanidm down first.
The kanidm_unixd process now wants access to /etc/shadow and /etc/group,
so it can rule out collisions with the host system.
Now migrations are run only on upgrade / downgrade and first start,
which makes netbox much faster on a normal start.
add the reindex for NetBox > 3.5.0, to populate the index, preventing
empty search results.
Migrations were moved out of netbox-migration.service into
netbox.service, to prevent service dependency issues when upgrading
NixOS.
This commit updates the binfmt magic-patterns using
f5e6786de4/scripts/qemu-binfmt-conf.sh
The patterns prior to this commit did not understand the difference
between mips32-*-* (32-bit void*,int) and mips64-*-*abin32 (32-bit
void*, 64-bit int). This commit corrects that.
Unfortunately there's no test for me to confirm that it works,
so all I can do is ask for maintainers, unfortunately -- I mean...
This is your opportunity!
When extending this module, it might be necessary to run something
from the package that's used in `matrix-synapse.service` (e.g. for
workers).
Now this can be trivially done by using
`config.services.matrix-synapse.package`. Previously it was necessary to
reuse the `PYTHONPATH` from the environment of `matrix-synapse.service`,
but that one doesn't exist anymore.
In some setups, and especially with sytemd-networkd becoming more widely
used, networking.useDHCP is set to false. Despite this, it may be useful
to have dhcp in the initramfs.
https://github.com/matrix-org/matrix-appservice-irc/releases/tag/1.0.0
* This release drops support for Node 16. The minimum required version is now 18+.
* Moved from NPM to Yarn
https://github.com/matrix-org/matrix-appservice-irc/releases/tag/1.0.1
* Fixes for GHSA-vc7j-h8xg-fv5x.
* Fixes for GHSA-3pmj-jqqp-2mj3.
* Fixes for GHSA-c7hh-3v6c-fj4q
* Update matrix-appservice-bridge to 9.0.1
while there was an effort to make this package with `mkYarnPackage`, in the end it
was suggested to just use `stdenv.mkDerivation` instead
nixos/matrix-appservice-irc:
* fix path to config.schema.yml directory stucture of the package changed
* use remarshal instead of python and pyyaml
to convert the config schema from yaml to json
When a dependency, like postgresql.service or redis-gitlab.service, had
been stopped and started at switch-to-configuration time, gitlab.service
and its helper units had been stopped but not started again.
`multi-user.target` only has a `Wants` relation to gitlab.target, but
once gitlab.target has been successfully started once and is not stopped/
restarted again, it does not cause all its dependencies to stay activated
the whole time.
This commit fixes this by upgrading the dependy relationship of
gitlab.service towards gitlab.target from a "Wants" to a "Requires". It
should be enough to do this for this single unit part of gitlab.target
only, as all other units wantedBy gitlab.target are pulled in by
gitlab.service as well or have bindsTo relations.
Simplify the SystemcallFilter by employing an explicit allow list, and
an explicit block list.
Node since version 18 requires syscalls in the @pkey group.
Excluding @privileged and @resources is a recommendation in
systemd-analyze.
nginx adds a `content-type: application/octet-stream` header by
default, and `add_header` does not supplant it. By setting
`default_type` instead we avoid the extraneous header.
If emacs starts before the graphical session is initialised, clients won't be
able to open new frames in the session. Start emacs with the graphical session
to avoid this issue.
Fixes https://github.com/NixOS/nixpkgs/issues/224512
Frigate does string prefix matching for paths, which isn't exactly
compatible with dynamically provisioned directories of systemd, where
/var/cache/frigate is actually a symlink to /var/cache/private/frigate.
Because we are unlikely to get this fixed upstream, this is one of the
reason we should stop using DynamicUser= here.
The other being, that nginx needs to be able to serve clips and
recordings from both the CacheDirectory and the StateDirectory, and
nginx being a member on a group that may only exist after it was started
up doesn't work reliably.
This is also why we relax the umask to allow g+r/g+rx for newly created
files. Existing installs may need the following permissions fix to get
things going.
```
find /var/lib/frigate/recordings -type d -exec chmod g+rx {} \;
find /var/lib/frigate/recordings -type f -exec chmod g+r {} \;
find /var/cache/frigate -type f -exec chmod g+r {} \;
```
Co-Authored-By: Daniel Barlow <dan@telent.net>
Because the local database is used by the osquery deamon, running
osqueri fails with:
IO error: While lock file: /var/lib/osquery/osquery.db/LOCK: Resource temporarily unavailable
Being wanted by and ordered before local-fs.target isn't strictly
correct. And in systemd initrd, it's very incorrect because
local-fs.target is for the initrd file system, not the real root file
system.
If one sets either of `override{Device,folder}s` to false, the jq `*`
operator doesn't merge well the devices and folders, creating duplicate
IDs for folders as observed in #230146. This PR makes the script iterate
via Nix / Bash loop the devices and folders IDs and merges the keys
using upstream's `curl -X POST` support for single objects.
Hence this commit fixes#230146.
Although 'lib' isn't needed by the default configuration, new NixOS uses
can get confused when being recommended configuration.nix snippets like
systemd.services.NetworkManager-wait-online.enable = lib.mkForce false;
and have `sudo nixos-rebuild switch` fail with
error: undefined variable 'lib'
This checks the validity of both NAT64 and SIIT configurations
at build time. An error produces something like this:
Validating Jool configuration... Error: Cannot parse '283.0.113.1' as an IPv4 address.
Build logs show:
> configure: WARNING: non-linux system; not building mount
> configure: WARNING: non-linux system; not building swapon
So skip these on non-Linux
Using getOutput prevents eval failures on other platforms.
Things should stay eval'able with NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1
Co-authored-by: Artturin <Artturin@artturin.com>
got broken in 6ea1a2a1be which changed
runCommandCC to runCommand but was not
noticed because it was failing silently
runCommand doesn't include CC or bintools
This patch adds an `authType` option to enable configuring FreshRSS's
`auth_type` parameter.
Upstream documentation for this feature is located here:
https://freshrss.github.io/FreshRSS/en/admins/09_AccessControl.html
An accompanying NixOS test is provided to confirm this feature works
as expected.
Upstream supports php 8.0/8.1 for the 3.3.0 release. The upgrade to 8.2
caused a type mismatch in carbon.
> PHP message: Exception: Code: 0, Message: Carbon\Carbon::setLastErrors(): Argument #1 ($lastErrors) must be of type array, bool given, called in /nix/store/2prnw9qya9kaks2rwvd6fkrz0c7l5ygd-engelsystem-3.3.0/share/engelsystem/vendor/nesbot/carbon/src/Carbon/Traits/Creator.php on line 98, File: vendor/nesbot/carbon/src/Carbon/Traits/Creator.php:928
With this change we allow the user to configure extras, exposed as
optional-dependencies on the matrix-synapse package.
The vertical integration between package, user configuration and
deployment is a huge boon which then allows us to dynamically adapt the
python environment the service runs in, by inspecting the configuration
and autodiscovering certain used extras from config paths.
Fix for Gitea 1.20.0.
Without this being set, e.g. a `git push` (or `ssh` to `git@` in general) fails like this:
2023/07/17 09:27:05 ...s/setting/setting.go:109:LoadCommonSettings() [F] Unable to load settings from config: unable to create chunked upload directory: /nix/store/yna9nf66wl2n9hlnhxi2g7fdgawk2kxl-gitea-1.20.0/bin/data/tmp/package-upload (mkdir /nix/store/yna9nf66wl2n9hlnhxi2g7fdgawk2kxl-gitea-1.20.0/bin/data: read-only file system)
Connection to git.mbosch.me closed.
Add `keyboards` option to define different configurations for different IDs. This creates the appropriate files in `/etc/keyd` instead of just `default.conf` as before.
Add `23.11` release note entry.
Add `mkRemovedOptionModule` for the old API with a note on how to revert the old behavior.
I initially thought it was related to /var/lib/nixos/{gid-map,uid-map},
but it seems that to migrate GID/UID you have to edit
/etc/{group,passwd} (and update GID/UID in all files). So mention those
files in the warning messages.
swraid support will now only be enabled by default if stateVersion is
older than 23.11. nixos-generate-config will now generate explicit
config for enabling support if needed.
The abstraction/nameservice profile from apparmor-profiles package
includes abstractions/nss-systemd. Without "reexporting" it,
the include fails and we get some errors.
