Follow-up for #25368.
Let's consider ENOENT an expected error, and just debug log about it
(though, let's suffix it with `, ignoring.`). All other errors will log
loudly, as they are unexpected errors.
ussually if you specify a DNS server on some interface then we'll use
that interface to talk to it. Let's override this for localhost
addresses, as they only really make sense on "lo".
Fixes: #25397
We only allow a selected subset of syscalls from nspawn containers
and don't list any time64 variants (needed for 32-bit arches when
built using TIME_BITS=64, which is relatively new).
We allow sched_rr_get_interval which cpython's test suite makes
use of, but we don't allow sched_rr_get_interval_time64.
The test failures when run in an arm32 nspawn container on an arm64 host
were as follows:
```
======================================================================
ERROR: test_sched_rr_get_interval (test.test_posix.PosixTester.test_sched_rr_get_interval)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/tmp/portage/dev-lang/python-3.11.0_p1/work/Python-3.11.0/Lib/test/test_posix.py", line 1180, in test_sched_rr_get_interval
interval = posix.sched_rr_get_interval(0)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 1] Operation not permitted
```
Then strace showed:
```
sched_rr_get_interval_time64(0, 0xffbbd4a0) = -1 EPERM (Operation not permitted)
```
This appears to be the only time64 syscall that isn't already included one of
the sets listed in nspawn-seccomp.c that has a non-time64 variant. Checked
over each of the time64 syscalls known to systemd and verified that none
of the others had a non-time64-variant whitelisted in nspawn other than
sched_rr_get_interval.
Bug: https://bugs.gentoo.org/880131
The existing logic can't find the root device in scenarios where
the root has been replaced with an overlay. We support looking
at "/run/systemd/volatile-root" to find the original root, similar
to what systemd-repart and gpt-auto-generator do.
- Use inst_recursive() and image_install() helpers where appropriate
- Update comments to explain why we need to install the test data manually in
$initdir
- Install manual/ in $initdir as TEST-35-LOGIN relies on
manual/test-session-properties
Instead of having fopen_temporary() create the file either next
to an existing file or in tmp/, let's split this up clearly into
two different functions, one for creating temporary files next to
existing files, and one for creating a temporary file in a directory.
systemd supports /etc/machine-id to be set to: uninitialized
In this case the expectation is that systemd creates a new
machine ID and replaces the value 'uninitialized' with the
effective machine id. In the scope of kernel-install we
should also enforce the creation of a new machine id in this
condition
systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR
policy:
$ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto
--tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img
ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001).
WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001
ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001).
WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000
New TPM2 token enrolled as key slot 1.
The problem seems to be that Esys_LoadExternal() function from tpm2-tss
expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not
a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() ->
iesys_handle_to_tpm_handle() call chain).
It all works because Esys_LoadExternal_Async() falls back to using the
supplied values when iesys_handle_to_tpm_handle() fails:
r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy);
if (r != TSS2_RC_SUCCESS) {
...
tpm_hierarchy = hierarchy;
}
Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions
(pre https://github.com/tpm2-software/tpm2-tss/pull/1531), use meson magic
to preserve compatibility.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
If we call raise(), we lose the information from the original signal.
If we use rt_sigqueueinfo(), the original siginfo gets reused which
is helpful when debugging crashes.
We use mkfs.xfs's protofile (-p) support to achieve this. The
protofile is a description of the files that should be copied into
the filesystem. The format is described in the manpage of mkfs.xfs.
systemd-boot expects being loaded from ESP and is quite unhappy in case
the loaded image device path is something else. When running on qemu
this can easily happen though. Case one is direct kernel boot, i.e.
loading via 'qemu -kernel systemd-bootx64.efi'. Case two is sd-boot
being added to the ovmf firmware image and being loaded from there.
This patch detects both cases and goes inspect all file systems known to
the firmware, trying to find the ESP. When present the
VMMBootOrderNNNN variables are used to inspect the file systems in the
given order.
Yu Watanabe
Mike Yuan
Lennart Poettering
Sam James
reuben olinsky
Li kunyu
Franck Bui
Luca Boccassi
Daan De Meyer
Jason A. Donenfeld
Edson Juliano Drosdeck
Marcus Schäfer
Vitaly Kuznetsov
Gerd Hoffmann
Zbigniew Jędrzejewski-Szmek