Having this function which is called only from one place in a separate file
makes the code harder to follow. In preparation for subsequent changes, let's
make it static.
This should help visualize where one manager's territory begins and
another's starts. Do this by underlining (since it's a "cut" point an
underline made most sense to me). Since underlining is not visible on
the console let's also show an ellipses for all lines that are
delegation boundaries.
Unfortunately this all is not as useful as it appears. The
"trusted.delegate" xattr is only visible to roo, which means
"systemd-cgls" has be called as root to show the boundaries.
Unfortunately cgroupfs doesn't support unprivileged xattrs on cgroups.
Let's mark cgroups that are delegation boundaries to us. This can then
be used by tools such as "systemd-cgls" to show where the next manager
takes over.
Previously we'd only skip ProtectHostname= if kernel support for
namespaces was lacking. With this change we also accept if unshare()
fails because it is blocked.
In some containers unshare() is made unavailable entirely. Let's deal
with this that more gracefully and disable our sandboxing of services
then, so that we work in a container, under the assumption the container
manager is then responsible for sandboxing if we can't do it ourselves.
Previously, we'd insist on sandboxing as soon as any form of BindPath=
is used. With this change we only insist on it if we have a setting like
that where source and destination differ, i.e. there's a mapping
established that actually rearranges things, and thus would result in
systematically different behaviour if skipped (as opposed to mappings
that just make stuff read-only/writable that otherwise arent').
(Let's also update a test that intended to test for this behaviour with
a more specific configuration that still triggers the behaviour with
this change in place)
Fixes: #13955
(For testing purposes unshare() can easily be blocked with
systemd-nspawn --system-call-filter=~unshare.)
Was getting:
../src/id128/id128.c:15:1: error: initializer element is not constant
static sd_id128_t arg_app = SD_ID128_NULL;
^
when building on CentOS 7.
Other parts of the code initialize `static sd_id128_t` to {} and this
was the original setting before a19fdd66c2 anyways.
This sould make our test suite a bit more robust if it is slow running.
A few of our test services use StandardOutput=tty or StandardError=tty
in the tests in order to connect test services to the container console.
This gets into conflict with the container getty which wants exclusive
access to the console. Since the container getty is started with
Type=idle it typically gets started after a timeout only if the TTY is
already used, which hence introduces a race: if the test finishes
earlier all is good, if not, then the test gets kicked off the TTY which
then causes bash to abort since it cannot write any error messages
anymore.
Let's fix this hence: all tests that connect to the tty are now
synchronized to getty-pre.target, so they finish before any getty is
started.
Note that this slightly changes behaviour: "none" is only allowed as
option, if it's the only option specified, but not in combination with
other options. I think this makes more sense, since it's the choice when
no options shall be specified.
It's not really clear which PAM errors to use for which conditions, but
something called PAM_SYSTEM_ERR should probably not be used when the
error is not the result of some system call failure.
This makes the naming more consistent: we now have
bootctl systemd-efi-options,
$SYSTEMD_EFI_OPTIONS
and the SystemdOptions EFI variable.
(SystemdEFIOptions would be redundant, because it is only used in the context
of efivars, and users don't interact with that name directly.)
bootctl is adjusted to use 2sp indentation, similarly to systemctl and other
programs.
Remove the prefix with the old name from 'bootctl systemd-efi-options' output,
since it's redundant and we don't want the old name anyway.
