Ryan Wilson [Sat, 30 Nov 2024 22:14:35 +0000 (14:14 -0800)]
core: Set /proc/pid/setgroups to allow for PrivateUsers=full
When trying to run dbus-broker in a systemd unit with PrivateUsers=full,
we see dbus-broker fails with EPERM at `util_audit_drop_permissions`.
The root cause is dbus-broker calls the setgroups() system call and this
is disallowed via systemd's implementation of PrivateUsers= by setting
/proc/pid/setgroups = deny. This is done to remediate potential privilege
escalation vulnerabilities in user namespaces where an attacker can remove
supplementary groups and gain access to resources where those groups are
restricted.
However, for OS-like containers, setgroups() is a pretty common API and
disabling it is not feasible. So we allow setgroups() by setting
/proc/pid/setgroups to allow in PrivateUsers=full. Note security conscious
users can still use SystemCallFilter= to disable setgroups() if they want
to specifically prevent this system call.
Ryan Wilson [Fri, 15 Nov 2024 14:56:05 +0000 (06:56 -0800)]
core: Add PrivateUsers=full
Recently, PrivateUsers=identity was added to support mapping the first
65536 UIDs/GIDs from parent to the child namespace and mapping the other
UID/GIDs to the nobody user.
However, there are use cases where users have UIDs/GIDs > 65536 and need
to do a similar identity mapping. Moreover, in some of those cases, users
want a full identity mapping from 0 -> UID_MAX.
Note to differentiate ourselves from the init user namespace, we need to
set up the uid_map/gid_map like:
```
0 0 1
1 1 UINT32_MAX - 1
```
as the init user namedspace uses `0 0 UINT32_MAX` and some applications -
like systemd itself - determine if its a non-init user namespace based on
uid_map/gid_map files. Note systemd will remove this heuristic in
running_in_userns() in version 258 and uses namespace inode. But some users
may be running a container image with older systemd < 258 so we keep this
hack until version 259.
To support this, we add PrivateUsers=full that does identity mapping for
all available UID/GIDs.
test-time-util: do more suppression of time zone checks
The issue is directly triggered by tzdata-2024b, where the setting of timezone
started to fail and the tests stopped passing. But those timestamps in 1/1/1970
appear to have some problems already before:
$ sudo date -s 'Thu 1970-01-01 13:00:01 WET'
Thu Jan 1 03:00:01 PM EET 1970
$ sudo date -s 'Thu 1970-01-01 12:00:01 WET'
date: cannot set date: Invalid argument
Thu Jan 1 02:00:01 PM EET 1970
$ rpm -q tzdata
tzdata-2024a-9.fc41.noarch
The same issue appears with other timezones. So move the first timestamp one
day forward to avoid the issue.
After the previous problem is solved, we also get the problem already seen
previously where the roundtrip returns a time that is off by one hour:
@86401000000 → Fri 1970-01-02 00:00:01 WET → @82801000000 → Thu 1970-01-01 23:00:01 WET
Assertion 'x / USEC_PER_SEC == y / USEC_PER_SEC' failed at src/test/test-time-util.c:415, function test_format_timestamp_impl(). Aborting.
Daan De Meyer [Thu, 5 Dec 2024 13:01:08 +0000 (14:01 +0100)]
test: Implement TEST_PREFER_QEMU and use it in one of the mkosi jobs
We want to make sure the integration tests that don't require qemu
can run successfully both in an nspawn container and in a qemu VM.
So let's add one more knob TEST_PREFER_QEMU=1 to run jobs that normally
require nspawn in qemu instead.
Running these tests in qemu is also possible by not running as root but
that's very implicit so we add an explicit knob instead to make it explicit
that we want to run these in qemu instead of nspawn.
docs/CONTRIBUTING: adjust grammar, info about tests and labels
Unfortunately our CI fails pretty much constantly, so instead of saying that
"tests don't pass", weasel this into "unit tests don't pass". Also fix grammar.
Labels are adjusted automatically now, so remove that sentence.
* 433efb38f4 Only apply the new Recommends in fedora
* 8dc31eaf04 Recommend qemu-kvm-core instead of qemu-kvm
* 53cfdea02a Update tmpfiles --destroy-data patch
* 04f0a692da Version 257~rc3
* 243a055429 Make systemd-network-generator co-owned by -udev and -networkd
* 37c10f5b03 Pull in qemu from systemd-container
This patch initially also changed the configuration, but that'll be done in a
different way, so all that remains is the syntax change.
An array is nicer because the array definition can have inline comments and
doesn't use continuation symbols which are easy to mess up in edits.
Bastien Nocera [Fri, 29 Nov 2024 21:20:29 +0000 (22:20 +0100)]
hwdb: Make 3D mice work out-of-the-box
According to https://en.wikipedia.org/wiki/3Dconnexion, 3D mice are:
human interface devices for manipulating and navigating
computer-generated 3D imagery. These devices are often referred to as
3D motion controllers, 3D navigation devices, 6DOF devices (six
degrees of freedom) or a 3D mouse.
Applications that want to support 3D mice on Linux are expected to
either use spacenavd and its library, or consume the HID output
directly.
This patch makes it possible for a number of applications that use 3D
mice directly to work out of the box, such as PrusaSlicer and its
derivatives.
basic/namespace-util: fix double logging after fork failure
[ 10.056930] (journald)[104]: Failed to fork off '(sd-mkuserns)': Invalid argument
[ 10.063727] systemd[1]: systemd-modules-load.service: About to execute: /usr/lib/systemd/systemd-modules-load
[ 10.071148] (journald)[104]: Failed to fork process (sd-mkuserns): Invalid argument
safe_fork_full() already logs at debug level, so the caller shouldn't.
pid1: assume user namespaces are unavailable if we get -EINVAL from clone()
As reported in https://github.com/systemd/systemd/issues/35400,
on riscv64, with Linux version 6.6.51-linux4microchip+fpga-2024.09, we get:
[ 10.063727] systemd[1]: systemd-modules-load.service: About to execute: /usr/lib/systemd/systemd-modules-load
[ 10.071148] (journald)[104]: Failed to fork process (sd-mkuserns): Invalid argument
meson: install README.logs independently of HAVE_SYSV_COMPAT
That file provides compatiblity (or more precisely the explanation for the lack
of compatibility) with syslog daemons. Those are used quite independently of
sysvinit. For example, RHEL uses rsyslog with systemd. We create
/var/log/journal, so it's no biggie to also provide /var/log/README with the
explanation. Let's keep it, since it might help some confused users, even when
compat with sysvinit is gone.
Yu Watanabe [Tue, 26 Nov 2024 15:06:39 +0000 (00:06 +0900)]
TEST-67-INTEGRITY: modernize test code
- make udevd generate debugging logs for loopback and DM devices,
- insert 'udevadm wait' at several places to make the device processed
by udevd,
- cleanup generated integritysetup service before moving to next
algorithm,
- drop unnecessary exit on command failure,
- also test data splitting mode for all algorithms.
let's just check the debug invocation boolean, and not recheck the
restart mode again. It's mostly redundant (because the boolean should
not have been become true if the restart mode was not set accordingly).
Moreover, i think we might want to eventually allow a manual way to
enable debug invocation mode, and hence this pointless checking would
become a problem.
Also, we never check the restart mode again in other cases, hence we
shouldn't here either.
tests: fix access mode of root inode of throw-away container images
Otherwise the root inode will typically have what mkdtemp sets up, which
is something like 0700, which is weird and somewhat broken when trying
to look into containers from unpriv users.
nspawn: don't try to unregister a machine we never registered
When registering we condition this on "arg_register". Let's do the same
when unregistering, otherwise we might end up trying to unregister a
machine we never registered.
Adrian Vovk [Tue, 1 Oct 2024 20:54:22 +0000 (22:54 +0200)]
bootspec: Look at /loader/addons in XBOOTLDR
The bootspec util-lib's handling of global addons didn't previously
match the behavior of sd-stub, and this commit corrects that.
First, bootspec didn't load global addons from the XBOOTLDR dir, but the
stub does. So, bootspec now enumerates addons in XBOOTLDR, not just ESP
Second, the stub only loads resources (including addons) from the
partition that it was found on. Thus, we must keep track of which
partition the global addons come from, and which partition each boot
entry comes from. In other words: global addons found on the ESP will
NOT apply to UKIs found in XBOOTLDR, and bootspec now reflects that.
projects / thirdparty / systemd.git / log
