This delegates one or more namespaces to the service. Concretely,
this setting influences in which order we unshare namespaces. Delegated
namespaces are unshared *after* the user namespace is unshared. Other
namespaces are unshared *before* the user namespace is unshared.
Fixes#35369
Two error conditions are unreachable, as now both glibc and kernel
support statx(). In other many places, failure in statx() are handled as
critical, even if it is filtered by seccomp or so. Let's follow the same
way here.
struct statx in glibc header was introduced in glibc-2.28
(fd70af45528d59a00eb3190ef6706cb299488fcd), but at that time,
sys/stat.h conflicts with linux/stat.h. Since glibc-2.30
(5dad6ffbb2b76215cfcd38c3001778536ada8e8a), sys/stat.h includes
linux/stat.h if exists.
Since now our baseline of glibc is 2.31. Hence, we can drop workarounds
for struct statx by importing linux/stat.h from newer kernel (v6.14-rc4).
The current glibc versions used by major distributions:
CentOS 9: 2.34
CentOS 10: 2.39
Fedora 40: 2.39
Fedora 41: 2.40
Fedora 42: 2.41
Ubuntu 20.04 LTS (focal): 2.31
Ubuntu 22.04 LTS (jammy): 2.35
Ubuntu 24.04 LTS (noble): 2.39
Ubuntu 24.10 (oracular): 2.40
Debian 11 (Bullseye, oldstable): 2.31
Debian 12 (Bookworm, stable): 2.36
openSUSE SLE-15-SP6: 2.38
openSUSE Tumbleweed: 2.40
Hence, based on our supporting policy, we can bump the base line to 2.31.
This commit does not change anything on our source code. But, will drop
many workarounds for supporting older glibc in later commits.
- split out verifications into two functions,
- also check the following scenarios:
* unmanaging an existing interface,
* re-managing an unmanaged interface,
* adding a new unmanaged interface,
* removing an unmanaged interface.
This is mostly a strawman to get a discussion going regarding how to
communicate to terminal emulators such as ptyxis about run0 (and nspawn,
and vmspawn, and moe) and what it does.
It's hierarchical and I think still relatively simple.
/cc @chergert
Since kernel v4.14, more specifically, after the following four commits,
e46abbcc05b7263e071a387454901b6150957521
the maximum length of nftable identifiers are extended to 255.
Now, our kernel baseline is 5.4, hence we can freely use the extended
name length.
This also modernizes code a bit, and adds test cases.
Closes#36542.
fido2_generate_hmac_hash() sets req->keyring to "fido2-pin" when
calling ask_password_auto(), suggesting that a key by this name
can be read from the kernel keyring. But the keyring is never
opened because the ASK_PASSWORD_ACCEPT_CACHED flag is not set.
Set ASK_PASSWORD_ACCEPT_CACHED to allow automated / scripted
setup of encrypted volumes with FIDO2. If the PIN turns out to
be invalid, clear ASK_PASSWORD_ACCEPT_CACHED to avoid retrying
and possible lockout.
Let's "spoil" access to TPM secrets when we boot into these two modes.
This matters in particular for storagetm: if the host gets exploited
while booted into storage target mode any secrets kept by the TPM might
remain accessible otherwise. By measuring a new "phase" word into PCR 11
we "blow the fuse" however on this boot.
(Note: we also change TEST-13-NSPAWN.machined.sh minimally here, because
it checks for byte precise output of a pty allocated for a service
invocation - which it's not going to get if it claims that the pty is an
all-powerful one. After all this PR ensures that we'll generate the new
OSC sequence on non-dumb terminals associated with services. Hence, set
TERM=dumb explicitly to ensure no ANSI sequences are generated, ever.
Which is a nice test btw that TERM=dumb really does its thing here.)
So far we conditioned the logic that issues ansi sequences for resetting
the TTY based on whether something is a pty is not (under the assumption
we need no reset on ptys, since they are shortlived).
This is simply wrong though. The pty that a container getty is invoked
on is generally long-lived: as long as the container is up, and it will
be reused between getty instances/sessions all the time. In such a case
we really should reset properly.
Let's instead make the logic dependent on whether TERM is set to
anything other than "dumb". The previous commit made sure we always set
TERM in a sensible way in systemd-run, hence this
*explicit* logic sounds like a much better choice now, as it mea
let's convert the 2nd argumeng form a boolean to a proper flags
parameter. Doesn't change behaviour in anyway, but is more readable, and
prepares ground for adding more flags soon.
There are two cases when we invoke a service on a TTY:
1. We ourselves are connected to a TTY and would intend to enable PTY
forwarding.
2. We are allocating a TTY but are not ourselves connected to a TTY and
just want to input/output to pipe or other non-TTY fd.
Let's propagate $TERM only as-is in the first case. In the 2nd case,
let's explicitly set $TERM to "dumb", so that invoked progams do not
issue needless ansi sequences, since we are not propagating them to a
terminal either.
This should be a much safer result, for cases where people include
invocations of systemd-nspawn with full TTY allocation in a shell
pipeline or so.
(of course, the user can always explicitly override this)
note: this also adds making a copy of the session type string after
registering the session. That's because we need to check the session
type we settled on later to condition out the OSC sequence (because it
should only be issued on TTY sessions). However, the session type string
originally quite likely points into the PAM environment block, which we
update in the meantime, invalidating that pointer. hence, make an
explicit copy first, and use that.
Preparation for adding offline signing support. Some additional
features and fixes are included as well:
- We make sure to add an empty SMIMECAP attribute instead of a populated
one to mimick pesign more.
- We switch to PKCS7_dataFinal() instead of PKCS7_final() as all that the
latter does is an unnecessary copy before calling PKCS7_dataFinal().
- We add support for passing in the signing time via $SOURCE_DATE_EPOCH.
