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