The json files were originally generated for Ubuntu stubble and are kown
to work since they ship in all Ubuntu arm64 ISOs by default.
Some of the devices might not be supported in mainline Linux yet and use
preliminary compatible strings.
If the option is not manually specified, and the hwids directory exists
for the target EFI architecture, default to it. Allow passing '' to skip.
Fixes https://github.com/systemd/systemd/issues/40542
These are meant to ship with ukify, in the same package,
so install them when ukify is enabled. Given they are
hardware-specific, use a per-arch subdirectory to make it
easier to enable them by default in ukify.
Add hwids json files for Snapdragon devices that use of this
feature since they don't ship with devie trees embedded in firmware.
The json files were originally generated for Ubuntu stubble and
are kown to work since they ship in all Ubuntu arm64 ISOs by default.
Some of the devices might not be supported in mainline Linux yet
and use preliminary compatible strings.
* 23a1c1fed9 Install /usr/lib/systemd/boot/hwids/ in ukify package
* 985170fdc6 Version 259.1
* 2e10d7da1e Revert getty changes a bit harder
* 96c683c3de Revert all remaing changes to getty@.service
* 24a305a398 Revert to previous handling of getty@.service
* 6a500eb814 Create getty@tty1.service again and move autovt@.service alias to /usr/lib
* 88bd4ab206 Properly enable systemd-tmpfiles-clear.service in scriptlets
* d9f3f02206 Raise the number of placeholder sections in kernel and addon stubs
* e301db0151 Stop enabling getty@tty1.service
* a1c33507a2 Fix unit names in systemd-udev scriptlet
* b7b3e024d6 Enable getty@.service through presets
* ec5e1b1ed7 Move tpm2 and getty support to -udev subpackage
* 9c9976a7f8 Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild
* f353d244fd Add 2 patches for automatic aarch64 DTB selection change
* 399885597c Revert "Disable sysinit-path for upstream builds"
TEST-74-AUX-UTILS.sh[3789]: + groupadd haldo
TEST-74-AUX-UTILS.sh[3875]: ==3875==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
Follow-up for 1012c6ce76
With the previous changes the modes for /tmp/ and /var/tmp/
may come in arbitrary directions, i.e. we may downgrade one
and upgrade another. Hence let's refactor the setup logic
a bit so they're truly independent.
As in the previous commit, checking for both requirements and ordering seems
unnecessary. In practical cases, the mount will be pulled in by the rest
of the transaction, so ordering is the part that matters. (The setup is
racy without the ordering.) If we drop the second check, the admin can
just use After=tmp.mount to achieve the desired behaviour, without needing
to explicitly pull in the unit. This is easier to configure and more robust.
This changes the implementation introduced in
6156bec7a4.
Also actually describe the implemented behaviour in the man page.
In https://github.com/systemd/systemd/issues/28515, multiple people report that
services that have PrivateTmp=yes and DefaultDependencies=no fail to create the
temporary directories under /tmp, when /tmp is e.g. a bind mount or some other
kind of mount that takes more time.
Before PrivateTmp=disconnected was added, we didn't have a nice solution:
DefaultDependencies=no is used to start services very early, so we wouldn't
want to add a dependency on /tmp automatically. With PrivateTmp=disconnected we
have a fairly nice solution. Let's "upgrade" to this mode automatically.
Strictly speaking, it is a small compat break, but in practice it's unlikely to
matter for early-boot services whether their /tmp is private or disconnected.
The dependency on /tmp that is checked is After. I think this is enough,
since any tmp.mount would be pulled in by local-fs.target and the rest of
the transaction anyway, so we don't need to check more than After.
The asserts are relaxed, because now the two settings can now diverge
in either way.
Resolves https://github.com/systemd/systemd/issues/28515.
[yhndnzj: fix unit_add_exec_dependencies() to handle the new
combination; add a comment in exec_needs_sys_admin()]
The only reason why ExecSharedRuntime.(var_)tmp_dir might
be suppressed is when (/var)/tmp/ is listed in InaccessiblePaths=,
in which case mount namespace is needed anyways. Moreover,
the current logic imposes a chicken-and-egg problem:
at various places in pid1 we'd need to check whether
the unit runs in a mountns, but the ExecSharedRuntime
may not be allocated for it just yet.
* Make sure we're not passing NULL to rmdir()
* Remove the inner "tmp" subdir as well, so that callers
can handle this transparently (e.g. exec_shared_runtime_make()
is not aware of the nested rmdir() requirements)
While at it, remove unneeded PROTECT_ERRNO.
These syscalls are part of a newer kernel API to replace interaction
with /proc/self/attr, with the goal of allowing LSM stacking. These are
being used now by e.g. libapparmor, so should be more easily available
to services using seccomp filtering.
We expose this via --private-users-delegate= which takes the number of
ranges to delegate. On top of delegating the ranges, we also mount in
the nsresourced socket and the mountfsd socket so that nested containers
can use nsresourced to allocate from the delegated ranges and mountfsd to
mount images.
Finally, we also create /run/systemd/dissect-root with systemd-tmpfiles to
make sure it is always available as unpriv users won't be able to create it
themselves.
test_sd_device_enumerator_filter_subsystem hangs forever in OBS builds,
as it waits for the udev queue to be drained. But this is not a booted
system, with systemd and udev, so nothing will do that.
Skip the test in that case.
ENOENT means /dev/loop-control isn't there which means we're in a
container and should go via mountfsd.
At the same time, reverse the check for fatal actions as almost all
actions can be done via mountfsd, only --attach needs the loop device.
- Allow foreign UID range
- Allow delegated UID ranges
Both of these can now be mapped by nsresourced into user namespaces
and hence should be accepted by mountfsd.
Whenever delegating UID ranges to a user namespace, it can also be
useful to map the foreign UID range, so that the container running in
the user namespace with delegated UID ranges can download container
images and unpack them to the foreign UID range.
Let's add an option mapForeign to make this possible. Note that this option
gives unprivileged users full access to the any foreign UID range owned directory
that they can access. Hence it is recommended (and already was recommended) to
store foreign UID range owned directories in a 0700 directory owned by the
owner of the tree to avoid access and modifications by other users.
This is already the case for the main users of the foreign UID range,
namely /var/lib/machines, /var/lib/portables and /home/<user> which all
use 0700 as their mode.
Users will also be able to create foreign UID range owned inodes in any
directories their own user can write to (on most systems this means /tmp,
/var/tmp and /home/<user>).
mkosi does all of its environment setup in an unprivileged user
namespace with an identity mapping. When it invokes nspawn and nspawn
tries to get a transient userns from nsresourced, this fails as no
transient ranges are mapped into mkosi's unprivileged userns (as doing
so would require privileges).
To fix this problem, let's allow allocating unprivileged self user
namespaces in nsresourced, similar to what the kernel allows, except that
we also support delegations for these. This means that mkosi can get its
unprivileged userns as before from nsresourced, but it can also request a
delegated 64K range inside that userns as well, which nsresourced can then
allocate to nspawn later when it asks for one.
Similar to the kernel, we disallow setgroups for self mappings. However,
instead of doing this via /proc/self/setgroups, which applies to the current
user namespace and all its child user namespaces, we use the BPF LSM to deny
setgroups instead, so that it can still be allowed for child user namespaces.
We need this because as soon as a container launches in a child user namespace
using one of the delegated mappings, it has to be able to do setgroups() to be
able to function properly.
To allow mapping the root user, we need to add the CAP_SETFCAP capability to
nsresourced.
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Tobias Heider
Daan De Meyer
Hosted Weblate
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Adrian Vovk
Nick Rosbrook
Daan De Meyer
Yu Watanabe