I have removed myself as maintainer from those packages that:
* Have at least one other maintainer
* Are outside of my actual expertise,
i.e. I wouldn't really know how to fix them if they broke
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.
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.
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.
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.
