This allows a single tmpfiles snippet with lines to symlink directories
from /usr/share/factory to be shared across many different configurations
while making sure symlinks only get created if the source actually exists.
We enumerate interfaces at first, then enumerate other configurations
like addresses and so on. If we are running on a container, previously
we started to configure the enumerated interfaces before enumerating other
configurations.
Let's configure interfaces after all configurations are enumerated.
Let's move the helper from nss-resolve.c to generic code, as it's going
to be useful in #34640.
Also, let's tighten the rules, and refuse negative ifindexes, because
they are invalid.
Some kernel SAS drivers (e.g. smartpqi) expose ports with num_phys = 0. udev
shouldn't treat these ports as wide ports. SAS wide ports always have
num_phys > 1. See comments for sas_port_add_phy() in the kernel sources.
Sample data from a smartpqi system to illustrate the issue below.
Here the phy device is attached to port 0:0, which has no end devices attached
and the SAS end device (where sda is attached) is associated with SAS
port 0:1, which has no associated phy device. Thus num_phys for port-0:1 is 0.
This is arguably wrong, but it's how smartpqi has always set up its devices in
sysfs.
/sys/class/sas_phy/phy-0:0 -> ../../devices/pci0000:46/0000:46:02.0/0000:47:00.0/host0/scsi_host/host0/phy-0:0/sas_phy/phy-0:0
/sys/devices/pci0000:46/0000:46:02.0/0000:47:00.0/host0/scsi_host/host0/port-0:0/phy-0:0 -> ../phy-0:0
/sys/devices/pci0000:46/0000:46:02.0/0000:47:00.0/host0/scsi_host/host0/phy-0:0/port -> ../port-0:0
/sys/class/sas_device/end_device-0:1 -> ../../devices/pci0000:46/0000:46:02.0/0000:47:00.0/host0/scsi_host/host0/port-0:1/end_device-0:1/sas_device/end_device-0:1
/sys/class/block/sda -> ../../devices/pci0000:46/0000:46:02.0/0000:47:00.0/host0/scsi_host/host0/port-0:1/end_device-0:1/target0:0:0/0:0:0:0/block/sda
Signed-off-by: Martin Wilck <mwilck@suse.com>
In mkosi, we want to support signing via a hardware token. We already
support this in systemd-repart and systemd-measure. However, if the
hardware token is protected by a pin, the pin is asked as many as 20
times when building an image as the pin is not cached and thus requested
again for every operation.
Let's introduce a custom openssl ui when we use engines and providers
and plug systemd-ask-password into the process. With
systemd-ask-password, the pin can be cached in the kernel keyring,
allowing us to reuse it without querying the user again every time to
enter the pin.
We use the private key URI as the keyring identifier so that the cached
pin can be shared across multiple tools.
In mkosi, we want to support signing via a hardware token. We already
support this in systemd-repart and systemd-measure. However, if the
hardware token is protected by a pin, the pin is asked as many as 20
times when building an image as the pin is not cached and thus requested
again for every operation.
Let's introduce a custom openssl ui when we use engines and providers
and plug systemd-ask-password into the process. With systemd-ask-password,
the pin can be cached in the kernel keyring, allowing us to reuse it without
querying the user again every time to enter the pin.
We use the private key URI as the keyring identifier so that the cached pin
can be shared across multiple tools.
Note that if the private key is pin protected, openssl will prompt both when
loading the private key using the pkcs11 engine and when actually signing the
roothash. To make sure our custom UI is used when signing the roothash, we have
to also configure it with ENGINE_ctrl() which takes a non-owning pointer to
the UI_METHOD object and its userdata object which we have to keep alive so we
introduce a new AskPasswordUserInterface struct which we use to keep both objects
alive together with the EVP_PKEY object.
Because the AskPasswordRequest struct stores non-owning pointers to its fields,
we change repart to store the private key URI as a global variable again instead
of the EVP_PKEY object so that we can use the private key argument as the keyring
field of the AskPasswordRequest instance without running into lifetime issues.
No functional change, at least now. Preparation for later commits.
But we are planning to extend KeepConfiguration= and also keep
addresses and so on assigned by other dynamic configuration protocol
like DHCPv6 or NDisc.
However, when link_free_engines() is called here, acquired addresses so
on by NDisc will be removed, even if link_stop_engines() handles
restarting networkd or KeepConfiguration= gracefully.
So, let's not free engines here, but free them later in link_free().
It is not necessary to be called here anyway.
The names of these conflict with macros from efi.h that we'll move
to efi-fundamental.h in a later commit. Let's avoid the conflict by
getting rid of these helpers. Arguably this also improves readability
by clearly indicating we're passing arbitrary strings and not constants
to the macros when we invoke them.
Currently ask_password_auto() will always try to store the password into
the user keyring. Let's make this configurable so that we can configure
ask_password_auto() into the session keyring. This is required when working
with user namespaces, as the user keyring is namespaced by user namespaces
which makes it impossible to share cached keys across user namespaces by using
the user namespace while this is possible with the session keyring.
With https://github.com/systemd/mkosi/pull/3164, we'll be able to run
arbitrary commands in the mkosi sandbox, which has /usr from the tools
tree if one is configured. Let's add the required packages to be able to
run meson to setup the integration tests. This allows running the integration
tests without having to install meson or other build dependencies on the
host system.
"""
mkosi sandbox meson setup build
mkosi sandbox meson compile -C build mkosi
mkosi sandbox env SYSTEMD_INTEGRATION_TESTS=1 meson test -C build ...
"""
Currently, bind-mounted directories within a user/mount namespace get
the uid/gid stored on their files. If the host creates a file in the
source directory, it will still show as root in the namespace.
Id-mapping is a filesystem feature that allows a mount namespace to show
a different uid than what is actually stored on a file. Add support for
id-mappings to exec directories, so that the files within the mount
namespace are owned by the unprivileged uid/gid.
Example:
Using unit:
```
[Unit]
Description=Sample service
[Service]
MountAPIVFS=yes
DynamicUser=yes
PrivateUsers=yes
TemporaryFileSystem=/run /var/opt /var/lib /vol
UMask=0000
ExecStart=/bin/bash -c 'while true; do echo "ping"; sleep 5; done'
StateDirectory=andresstatedir:sampleservice
[Install]
WantedBy=multi-user.target
```
In the host namespace, creating a file "test":
```
root@abeltran-test:/var/lib/andresstatedir# ls -lah
total 8.0K
drwxr-xr-x 2 root root 4.0K Aug 21 23:48 .
drwx------ 3 root root 4.0K Aug 21 23:47 ..
-rw-r--r-- 1 root root 0 Aug 21 23:48 test
```
Within the unit namespace:
```
root@abeltran-test:/var/lib/sampleservice# ls -lah
total 4.0K
drwxr-xr-x 2 63750 63750 4.0K Aug 21 23:48 .
drwxr-xr-x 3 root root 60 Aug 21 23:47 ..
-rw-r--r-- 1 63750 63750 0 Aug 21 23:48 test
```
```
root@abeltran-test:/# mount | grep and
/dev/sda1 on /var/lib/private/andresstatedir type ext4 (rw,nosuid,noexec,relatime,idmapped,discard,errors=remount-ro,commit=30)
```
The check for the old flag was not restored when the weak blocker was
added, add it back. Also skip polkit check for root for the weak
blocker, to keep compatibility with the previous behaviour.
Partially fixes https://github.com/systemd/systemd/issues/34091
Follow-up for 804874d26a
Luca Boccassi
Yu Watanabe
Daan De Meyer
Franck Bui
Lennart Poettering
Luca Boccassi
Colin Foster
Martin Wilck
dependabot[bot]
Ronan Pigott
Andres Beltran