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
Caddy 2.7.x does no longer return etags for files with unix modtimes of
0 and 1.
Files in /nix/store have a modtime of 1.
This is something that has been specifically implemented for nix.
For now, we decided to remove the test.
But I might reimplement a similar etag subtest some time in the future.
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.
https://github.com/NixOS/nixpkgs/pull/191540 indirectly broke kernel
passthru.tests; calling the testsForLinuxPackages and testsForKernel functions
with some args intended for some other exposed test-internal function.
Organise the passed-through functions under `passthru` to prevent this from
happening.
discoverTests tries to discover some sort of internal function and tries to call
it with the arguments for that internal function. This poses an issue when you
want to expose some other functions (i.e. a parameterisation for a test) in
nixosTests.
This commit allows a test to pass through arbitrary values via `.passthru`
without them having discovery applied to them; including functions.
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.
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).
