Let's move some logic from _DEFINE_MAIN_FUNCTION() and other places
in main-func.h into functions that we implement in main-func.c to
allow moving some included headers from the header to the .c file.
Now that the necessary functions from log.h have been moved to macro.h,
we can stop including log.h in macro.h. This requires modifying source
files all over the tree to include log.h instead.
Normally, the service manager sets $SHELL to the target user's
login shell, but run0 always overrides that with either
originating user's shell or value from --setenv=SHELL=. In both cases
$SHELL needs to be sent.
Fixes#35007
Follow-up for c8f59296bf
Currently, the unit is only reffed in transient_unit_set_properties()
via AddRef(), which however would be dropped if a reconnection
is attempted. Make sure to explicitly re-add reference in that case.
When we pass information about our calling terminal on to some service
or command we invoke, propagate $COLORTERM + $NO_COLOR in addition to
$TERM, in order to always consider the triplet of the three env vars the
real deal.
Admittedly, some of our glyphs _are_ special, e.g. "O=" for SPECIAL_GLYPH_TOUCH ;)
But we don't need this in the name. The very long names make some invocations
very wordy, e.g. special_glyph(SPECIAL_GLYPH_SLIGHTLY_UNHAPPY_SMILEY).
Also, I want to add GLYPH_SPACE, which is not special at all.
- Fixes a race in systemd-run caused by
b7ba8d55b8, which causes issue #36679.
- Skip verifying masked units in TEST-23.
- Avoid false-positive ASan warning by switching sanitizer run from
Fedora rawhide to Fedora 41, caused by recent update from
llvm-19.1.7-11.fc43 to llvm-20.1.0-1.fc43. Hopefully issue #36678 should
be fixed.
Closes#36678.
Closes#36679.
Otherwise, if systemd-run is disconnected from bus before JobRemoved
signal, then c->start_job will never freed, thus run_context_check_done()
will never call sd_event_exit() even after the service is finished.
This drops monitoring JobRemoved signal, and make systemd-run check if
the start job is started when PropertiesChanged signal is received.
Follow-up for b7ba8d55b8.
Fixes#36679.
In one of the next commits we'd like to introduce a concept of
optionally hashing the hostname from the machine ID. For that we we need
to optionally back gethostname_full() by code involving sd-id128, hence
let's move it from src/basic/ to src/shared/, since only there we are
allowed to use our public APIs.
Now our baseline of meson is 0.62, hence install_symlink() can be used.
Note, install_symlink() implies install_emptydir() for specified
install_dir. Hence, this also drops several unnecessary
install_emptydir() calls.
Note, the function currently does not support 'relative' and 'force' flags,
so several 'ln -frsT' inline calls cannot be replaced.
When services start up they might query for passwords, or issue polkit
requests. Hence it makese sense to run the password query agent and
polkit agent from systemd-run. We already ran the polkit agent, this
also ensures we run the password query agent.
There's one tweak to the story though: running the agents and the pty
forwarder concurrently is messy, since they both try to read from stdin
(one potentially, the other definitely). Hence, let's time the agents
properly: invoke them when we initialize, but stop them once the start
job for the unit we are supposed to run is complete, and only then run
the pty forwarder.
With this in place, the following series of commands starts to work
really nicely (which previously deadlocked):
# homectl create foobar
# run0 -u foobar
What happens in the background in run0 is this: a new session is invoked
for "foobar", which pulls in the user@.service instance for the user.
That user@.service instance will need to unlock the homedir first. Since
8af1b296cb this will happen via the askpw
logic. With this commit here this prompt will now be shown by run0. Once
the password is entered the directory is unlocked and the real session
begins. Nice!
This new behaviour is conditioned behind --pty-late (distinct from the
existing --pty switches). For systemd-run we will never enable this mode
by default, for compat with command lines that use ExecStartPre=
(because we won't process the pty anymore during that command) For
run0 however this changes the default to --pty-late (unless
--no-ask-password is specified). This reflects the fact that run0 is
more of an interctive tool and unlikely to be used in more complex
service start-up situations with ExecStartPre= and suchlike.
This also merges JobDoneContext into RunContext, since it doesn't really
make sense to have two contexts around to communicate between outer
stack frame and event handlers. Let's just have one, and pass it around
to all handlers the same way. In particular as we should delay exit only
until both the unit's job is complete *and* in case of --wait the unit
is exited, one of the two should not suffice.
We'll add another type of handler callback in the next commit, hence
rename the existing handler to be more precise what it is about:
handling hangups (either inline via tty, or explicit via user request)
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)
Let's move pam_systemd_home before pam_unix in the authentication hook.
Since a while we are exposing shadow entries for homed log entries via
NSS. This means that pam_unix now potentially has enough data for
authenticating a user on its own, without letting pam_systemd_home do
that. This is superficially OK, but also means that authentication will
always go via password, even if pkcs11/fido2 is registered.
Let's move this around, but be careful about it: let's list the precise
errors which we think are enough to terminating further PAM processing,
so that pam_unix comes into control in all cases where it's not clear
that pam_systemd_home owns the user record.
This previously wasn't visible to me, because on Fedora until authselect
1.5.1 (released earleir this year) the NSS shadow stuff was not enabled.
This does the same also for the "account" stack, except that the order
there already was as we want it.
Finally, shorten the account stack, by just requiring pam_unix.so and
dropping pam_permit.so, because it doesn't really serve much purpose
(and Fedora doesn't use it by default either.)
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
This adds a new --lightweight=yes/no switch which allows controlling
whether the invoked service will have the service manager around or not.
Moreover, this changes that if the target user is root it will now
support to the lightweight mode, i.e. run0 towards root will no longer
pull in the service manager (a real tty login via getty still will
though!).
My thinking here is that quickly raising privileges via run0 probably
shouldn't be considered a proper login but just something short lived,
temporary for a single command or similar.
Let's make sure systemd-run itself works nicely as a service that tells
the caller when it is ready.
Note that we don't fire the same message in scope mode, since in that
case want to leave sd_notify() handling to the invoked process.
This partially reverts 12807b5a49.
Otherwise, reading or writing a fd in on_exit_event() handler may return
EBUSY, and the event loop may finish with -ELOOP.
Also, this makes drained() returns true if the PTY forwarder is already
disconnected, for safety. Hence, it is not necessary to re-introduce
pty_forward_is_done().
Then, it is not necessary to manually drain PTY forwarder by the user
side. Also, not necessary to free PTY forwarder earlier explicitly to
make it disconnected.
We often used a pattern like if (!FLAGS_SET(flags, SD_JSON_FORMAT_OFF)),
which is rather verbose and also contains a double negative, which we try
to avoid. Add a little helper to avoid an explicit bit check.
This change clarifies an aditional thing: in some cases we treated
SD_JSON_FORMAT_OFF as a flag (flags & SD_JSON_FORMAT_OFF), while in other cases
we treated it as an independent enum value (flags == SD_JSON_FORMAT_OFF).
In the first form, flags like SD_JSON_FORMAT_SSE do _not_ turn the json
output on, while in the second form they do. Let's use the first form
everywhere.
No functional change intended.
Initially I wasn't sure if this helper should be made public or just internal,
but it seems such a common pattern that if we expose the flags, we might just
as well expose it too, to make life easier for any consumers.
We must be prepared that systemd temporarily drops off the bus or
disconnects our direct connections (due to systemctl daemon-reexec or
so). Hence automatically reconnect when we watch the unit status, and
handle this case gracefully.
Fixes: #32906#27204
Let's not confuse users with the login shell indicator and drop it from
the description. This means a run0 session will now usually show up with
a description of "[run0] /bin/bash" rather than "[run0] -/bin/bash".
I think we should try to communicate clearly if something is a run0
session, or a systemd-run invocation. Hence, let's initialize the
description so that the command is prefixed by
program_invocation_short_name.
Effectively this means that our run0 sessions now appear as services
with a description of "[run0] -/bin/bash"
The current logic is a bit complex how systemd-run units are called. It
used to be just the unique ID of the dbus connection. Which was nice,
since its system-widely, uniquely assigned to us. But this didn't work
out well, due to direct connections to PID 1 and due to soft reboots.
We nowadays have a better ID to use though, with nicer properties: the
kernel manages a pidfd ID for every process after all, and it's globally
unique, for any process, and regardless of soft reboots. Hence use that
for naming preferably, and just keep one branch with a randomized name
as fallback.
This makes use of the infra introduced in 229d4a9806 to indicate visually on each prompt that we are in superuser mode temporarily.
pick ad5de3222f userdbctl: add some basic client-side filtering
Mike Yuan
Daan De Meyer
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Gavin Li