Follow-up for cd911bec6e
The (debug) envvar should have highest priority, hence move it
to the new entrypoint function and give it precedence over
systemd.tpm2_measured_os=.
Before this commit, the > 0 state of arg_newline tristate is
simply ignored.
Yes, this is a minor compat break, but I'd argue the previous
behavior was not useful as "yes" is treated the same as "auto".
An issue also reported that it was quite surprising.
Fixes#41348
If length is exactly 16, the loop would finish with length == 0,
but we'd carry on to the memcmp() check, where the 'p + 16' passed
would be invalid memory. memcmp() demands valid pointers even if
size is specified to 0, hence let's catch this ourselves.
Follow-up for ab73333c43
Methods that take numeric pid values use 0 to denote the peer,
hence let's log about 0 on PIDREF_AUTOMATIC, -1 if truly unset.
Linux console is very weird when it comes to ANSI color sequences.
Not only that it isn't aware of ':' separator (c.f.
https://github.com/systemd/systemd/pull/40878#issuecomment-3979826739),
it even skips the whole CSI-m sequence if it contains parts it cannot
parse. Hence when color mode is set to 256 (i.e. default when no
extra info is available) let's always emit two distinct CSI-m sequences,
and set the fallback 16 color first in case the terminal doesn't have
complete support for the 256 one.
Replaces #40905
If a pidfd id is passed to us, it must have originated from
somewhere, i.e. pidfs should be supported on the system.
Hence let's be honest about -EOPNOTSUPP, which might indicate
some bigger problems under the hood, rather than allowing
it to be turned into mild -ESRCH.
History has clearly shown that we're terrible at keeping
the size of the dont_close array up-to-date. Hence let's
step away from a hardcoded max size for that, instead
always collect all fds in the array initializer and
let compiler figure it out, taking advantage of the fact
that close_all_fds() gracefully handles invalid fds in
the 'except' array.
Follow-up for 12001b1bf0
It is part of the keep_fds array already, which is intended
for fds that need to survive until the very end of executor
runtime, i.e. across the second close_all_fds() call.
The owned fds should be closed before close_all_fds() along the lines
of exec_params/runtime_close(), otherwise they would be left dangling
afterwards.
With the previous changes the modes for /tmp/ and /var/tmp/
may come in arbitrary directions, i.e. we may downgrade one
and upgrade another. Hence let's refactor the setup logic
a bit so they're truly independent.
The only reason why ExecSharedRuntime.(var_)tmp_dir might
be suppressed is when (/var)/tmp/ is listed in InaccessiblePaths=,
in which case mount namespace is needed anyways. Moreover,
the current logic imposes a chicken-and-egg problem:
at various places in pid1 we'd need to check whether
the unit runs in a mountns, but the ExecSharedRuntime
may not be allocated for it just yet.
* Make sure we're not passing NULL to rmdir()
* Remove the inner "tmp" subdir as well, so that callers
can handle this transparently (e.g. exec_shared_runtime_make()
is not aware of the nested rmdir() requirements)
While at it, remove unneeded PROTECT_ERRNO.
This reverts commit 351b4dd123.
I'm pretty sure we should not create more of these multiplexer
interfaces, which in this specific also leads to a fair bit of
confusion: start/stop/reload-or-restart --marked all enqueue
all job types.
Instead, a dedicated verb will be introduced in later commits.
Note that SD_VARLINK_ERROR_INVALID_PARAMETERS requires
the invalid param name to be specified, hence we would
otherwise have reported an invalid INVALID_PARAMETERS
error ;)
* Make sure ret is initialized on success return
* Drop unneeded 'object' variable
* No need to ref/unref json objects when constructing
intermediary array
For AF_UNIX sockets connection sources are accounted for
based on UID, hence in user scope this effectively
limits total number of connections, which is not really
desirable.
Follow-up for a109189fab
This follows the existing practice for
systemd-journal-{upload,gatewayd}.service,
as I think allocating a full-blown user
specifically for this purpose is an overkill.
And with DynamicUser=yes we can also take
advantage of implied sandboxing.
find_ovmf_config() would do filtering based on arg_secure_boot
already, hence the mismatch can only occur if we're using
user-specified firmware. So be explicit about this in log.
I expressed the issue I have with parse_tristate_argument()
in #37751: it doesn't add any value to direct use of parse_tristate();
on the contrary, it doesn't support means to reset the arg to "auto"/-1 state.
The mere reason it existed is that we need a int type ret param.
Since the previous attempt to address this mess failed, let's
try to make the function more useful by making it accept "auto".
I figure this is useful on its own.
As requested in
https://github.com/systemd/systemd/pull/40652#discussion_r2831833996,
the function name is suffixed with _with_auto() to establish
that "auto" is handled internally.
Mike Yuan