This is the first part of #38728, just the machined stuff, no the
importd stuff.
This definitely makes sense of its own, hence let's get this in first.
The original PR contains a tescase that tests machined + importd in
combination. This PR here hence is without a testcase, but it's there,
just in the other PR.
This looks large and is large, but do note that much of the machined
changes are very repetitive: they conditionalize PK checks to the system
version, as PK doesn't make sense in the use rversion.
We passes log level through kernel command line. It is not necessary to
set to debug level at the beginning, and set to info at the end.
This is important when a test has several subtests. If a subtest sets
log level to info at the end, then subsequent tests may not generate any
useful logs.
When HAVE_SECCOMP is not set, a build error happens:
../src/analyze/analyze-security.c: In function ‘get_security_info’:
../src/analyze/analyze-security.c:2449:13: error: unused variable ‘r’ [-Werror=unused-variable]
2449 | int r;
| ^
cc1: some warnings being treated as errors
Fix it by removing the sometimes unused variable.
Currently, cgroup_path is (de-)serialized after all the cached
accounting data. This is bogus though, since unit_set_cgroup_path()
destroys the CGroupRuntime object and starts afresh, discarding
all deserialized values. This matters especially for IP accounting,
whose BPF maps get recreated on reload/reexec and the previous values
are exclusively retrievable from deserialization. Let's hence swap things
around and serialize cgroup_path first, accounting data only afterwards.
discover-image.[ch] largely already supports per-scope operations, let's
extend this however to also cover finding .nspawn settings files and
managing the pool dir.
We intend to make self-registering machines an unprivileged operation,
but currently that would allow an unprivileged user to register a
process they own in the root namespace, and then login as any
user they like, including root, which is not ideal.
Forbid non-root from shelling into a machine that is running in
the root user namespace.
This caused resolved to only consider the 1st search domain of every
interface and ignore the rest.
Fixes a regression caused by 81ae2237c1 (v258).
Fixes#39118.
4971s TEST-74-AUX-UTILS.sh[1212]: + script -ec 'networkctl edit --runtime "$NETWORK_NAME"' /dev/null
4971s TEST-74-AUX-UTILS.sh[1269]: .//usr/lib/systemd/tests/testdata/units/TEST-74-AUX-UTILS.networkctl.sh: line 55: script: command not found
Currently works due to a transitive dependency somewhere else
that is being dropped, pull it in directly given the tool is
used by the tests
Currently it's next to impossible to find out why dissect_image()
has failed with EADDRNOTAVAIL, so let's add debug logging and use
EREMOTE for the different architectures error to help out with
debugging a bit.
When establishing a idmapped mount for a directory with foreign mapping
we so far insisted in the dir being properly opened (i.e. via a
non-O_PATH fd) being passed to mountfsd. This is problematic however,
since the client might not actually be able to open the dir (which after
all is owned by the foreign UID, not by the user). Hence, let's relax
the rules, and accept an O_PATH fd too (which the client can get even
without privs). This should be safe, since the load-bearing security
check is whether the dir has a parent owned by the client's UID, and
for that check O_PATH or not O_PATH is not relevant.
This is split out of #38764.
It mostly introduces the "chrome" stuff that puts a blue at the top of
bottom of the terminal screen when going through interactive tools such
as firstboot, homed-firstboot, and (in future) systemd-sysinstall).
it also introduces a generic "prompt_loop()" helper thatn queries the
user for some option in a loop until the rsponse matches certain
requirements. It's a generalization of a function of the same name that
so far only existed in firstboot.c. The more generic version will be
reused in a later PR by homed-firstboot and by sysinstall.
We'll soon have three different kind of interactive "wizard"-like console
UIs: systemd-firstboot, homectl firstboot and soon systemd-sysinstall.
Let's give them a limited, recognizable visual identity, to distinguish
them from the usual console output: let's add a bit of "chrome" to the
top and bottom of the screen, that we show during ther wizards, but hide
again afterwards.
This makes use of the DECSTBM sequence that reduces the scrolling area
by chopping off blocks from the top or bottom of the screen. The
sequence is quite standard, given it has been part of VT100 already.
xterm, vte, Linux console all support it just fine.
Current methods take a numeric PID, but we know that is unreliable for
the usual reasons. Add variants that take a PIDFD instead, or a
PID + PIDFDID combination for remote users.
let's place the cursor at the beginning of the line before/after, so we
know it's the first char we overwrite, and we return to the front again
right after.
So, UEFI's color texting is a bit weird. It translates everything to
ANSI sequences, but unlike ANSI sequences it has no understanding of a
distinct "default" bg/fg color, it assumes the ansi color "0" is always
equal to white on black, but that's of course not really true, most
terminal emulators at the very least support white background too.
tianocore then also tries to be smart and suppresses ANSI color changes
from a color to itself. But if the understanding of the color is wrong
in the first place, then any color change suppression like this hurts
more than it helps.
Then in addition there are certain terminal tools that will reset the bg
color on every line break ("less" for example) to the default.
Let's deal with that and improve the situation on all fronts:
1. force out color changes by doing two color changes whenever we really
want it.
2. on every newline force out the color change again.
with this in place, using sd-boot on a terminal emulator is a lot nicer.
Yu Watanabe
Matteo Croce
Mike Yuan
Lennart Poettering
Luca Boccassi
Mantas Mikulėnas
Daan De Meyer
Antonio Alvarez Feijoo