Nowadays, we define syscall numbers for newer syscalls.
Hence the conditions are not necessary.
This also adds several comments about when syscalls are introduced.
If a non-zero timeout is specified we should not bypass ppoll() even if
no fds are specified, since it will still act as a time based sleep in
that case.
I noticed that systemd-tty-password-agent would time out when asked to
stop via SIGTERM, and eventually be killed, under some circumstances.
It took me a while but i figured out what was going on:
systemd-ask-pw-agent blocks SIGTERM because it wants async notifications
on SIGTERM via signalfd() to listen on. That mostly works great: except
for one case: if we actually get a pw query request, and hence need to
acquire the terminal: we issue open_terminal() in that case, but if the
terminal is used otherwsie we'll hang, and because SIGTERM is blocked
we'll hang and cannot exit cleanly.
Address that: optionally, in acquire_terminal() look for SIGTERM by
unblcking the signal mask via ppoll() while we wait.
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).
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
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.
This has been depracted since v254 (2023). Let's kill it for
good now, it has been long enough with 2y. Noone has shown up who wants
to keep it. And given it doesn't work in SB world anyway, and is not
measured is quite problematic security wise.
Yu Watanabe
Lennart Poettering
Luca Boccassi
Mike Yuan