This allows for "per-instance" credentials for units. The use case
is best explained with an example. Currently all our getty units
have the following stanzas in their unit file:
"""
ImportCredential=agetty.*
ImportCredential=login.*
"""
This means that setting agetty.autologin=root as a system credential
will make every instance of our all our getty units autologin as the
root user. This prevents us from doing autologin on /dev/hvc0 while
still requiring manual login on all other ttys.
To solve the issue, we introduce support for renaming credentials with
ImportCredential=. This will allow us to add the following to e.g.
serial-getty@.service:
"""
ImportCredential=tty.serial.%I.agetty.*:agetty.
ImportCredential=tty.serial.%I.login.*:login.
"""
which for serial-getty@hvc0.service will make the service manager read
all credentials of the form "tty.serial.hvc0.agetty.xxx" and pass them
to the service in the form "agetty.xxx" (same goes for login). We can
apply the same to each of the getty units to allow setting agetty and
login credentials for individual ttys instead of globally.
Credentials are written to a temporary file and renamed to the
destination with renameat() which will replace existing files so
EEXIST should not happen so drop the handling for EEXIST.
All messages logged from exec_spawn() are attributed to the unit
and as such we should set the log level to the unit's max log level
for the duration of the function.
With ambient capabilities being dropped at the start of process managers
(both system and user) as well as systemd-executor it isn't necessary
to drop them here. Moreover, at this point also the inheritable set can
be preserved. This makes it possible to assign a user session manager
inheritable capabilities which combined with file capabilites (ei sets)
of service executables enable running user services with capabilities
but only when started by the manager.
This reverts commit 943800f4e7.
Since the commit 963b6b906e ("core: drop ambient capabilities in
user manager") systemd running as the session manager has dropped ambient
capabilities retaining other sets allowing user services to be started
with elevated capabilities. This, worked fine until the introduction of
sd-executor. For a non-root process to be started with elevated
capabilities by a non-root parent it either needs file capabilities or
ambient capabilities in the parent process. Thus, systemd needs to allow
sd-executor to inherit its ambient capabilities and sd-executor should
drop them as systemd did before.
The ambient set is managed for both system and session managers, but
with the default set for PID#1 being empty, this code does not affect
operation of PID#1.
Fixes: bb5232b6a3 ("core: add systemd-executor binary")
Since the copy helpers now copy file attributes as well, let's not
explicitly disable copy-on-write anymore when we copy an image. If
the source already has copy-on-write disabled, the copy will have it
disabled as well. Otherwise, the copy will also have copy-on-write
enabled.
This makes sure that reflinks always work as reflink is only supported
if both source and target are copy-on-write or both source and target
are not copy-on-write.
Follow-up for 6906c028e8
The mentioned commit uses access() to check if varlink socket
already exists in the filesystem, but that isn't sufficient.
> Varlink sockets are not serialized until v252, so upgrading from
> v251 or older means we will not listen anymore on the varlink sockets.
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074789
> for more details as this was found when updating from Debian Bullseye to a new version.
After this commit, the set up of varlink_server is effectively
split into two steps. manager_varlink_init_system(), which is
called after deserialization, would no longer skip listening
even if Manager.varlink_server is in place, but actually
check if we're listening on desired sockets.
Then, manager_deserialize() can be switched back to using
manager_setup_varlink_server().
Alternative to #33817
Co-authored-by: Luca Boccassi <bluca@debian.org>
It's important if the binary specified by the init= boot option is not systemd
otherwise it confuses systemctl that incorrectly assumes that systemd is still
the init system due to the presence of /run/systemd/system.
Also some tools might also check the presence of /run/systemd/private to test
if systemd is running as pid1.
When credentials are used with Type=simple + ExecStartPost=,
i.e. when multiple sd-executor instances are running in parallel
for a single service, the state of final credential dir
might be unexpected wrt path_is_mount_point() and other
steps. So, let's imply Type=exec if not explicitly specified,
and emit a warning otherwise.
Currently, we have a bunch of Type=oneshot + RemainAfterExit=yes
services that make use of credentials. When those exits, the cred mounts
remain established, which is pointless and quite annoying. Let's
instead destroy the runtime data on SERVICE_EXITED, if no process
will be spawned for the unit again.
In PID 1 we write status information to /dev/console regularly, but we
cannot keep it open continously, due to the kernel's SAK logic (which
would kill PID 1 if user hits SAK). But closing/reopening it all the
time really sucks for tty types that have no window size management
(such as serial terminals/hvc0 and suchlike), because it also means the
TTY is fully closed most of the time, and that resets the window sizes
to 0/0.
Now, we reinitialize the window size on every reopen, but that is a bit
expensive for simple status output. Hence, cache the window size in the
usualy $COLUMNS/$ROWS environment variables. We don't inherit these to
our payloads anyway, hence these are free to us to use.
It doesn't really make sense to have that in dev-setup.c, which is
mostly about setting up /dev/, creating device nodes and stuff.
let's move it to the other stuff that deals with /dev/console's
peculiarities.
It's a bit confusing, but we actually initialize the terminal twice for
each service, potentially. One earlier time, where we might end up
firing vhangup() and vt_disallocate(), which is a pretty brutal way to
reset things, by disconnecting and possibly invalidating the tty
completely. When we do this we do not keep any fd open afterwards, since
it quite likely points to a dead connection of a tty.
The 2nd time we initialize things when we actually want to use it.
The first initialization is hence "destructive" (killing any left-overs
from previous uses) the 2nd one "constructive" (preparing things for our
new use), if you so will.
Let's document this distinction in comments, and let's also move both
initializations to exec_invoke(), so that they are easier to see in their
symmetric behaviour. Moreover, let's run the tty initialization after we
opened both input and output, since we need both for doing the fancy
dimension auto init stuff now.
Oh, and of course, one thing to mention: we nowadays initialize
terminals both with ioctl() and with ansi sequences. But the latter
means we need an fd that is open for *write* (since we are *writing*
those ansi sequences to the tty). Hence, resetting via the input fd is
conceptually wrong, it worked only so far if we had O_RDWR open mode
selected)
Let's make sure to first issue the non-destructive operations, then
issue the hangup (for which we need the fd), then try to disallocate the
device (for which we don't need it anymore).
And while we are at it, merge exec_context_determine_tty_size() +
exec_context_apply_tty_size().
Let's simplify things, and merge the two funcs, since the latter just
does one more call.
At the same time, let's make sure we actually allow passing separate
input/output fds.
We nowadays reset TTYs by writing ANSI sequences to them. This can only
work if we operate on an *output* fd, not an input fd. Hence switch
various cases where we erroneously used an input fd to use an output fd
instead.
This is a lot of stuff, and sometimes quite wild, let's turn this into
its own header.
All stuff color-related that just generates sequences is now in
ansi-color.h (no .c file!), and everything more complex that
probes/ineracts with terminals remains in termina-util.[ch]
It has bugged me for a while that we show the exact same welcome message
at boot twice: once in the initrd, and once after the initrd→host
transition. That's very confusing.
Let's change the text a bit, and tone down the initrd message a bit (by
removing the empty line before and after it), because it is the less
relevant one.
Daan De Meyer
Michal Sekletar
Luca Boccassi
Łukasz Stelmach
Mike Yuan
Franck Bui
Lennart Poettering