This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
- drop unnecessary SYNTHETIC_ERRNO() when the logger does not propagate
error code,
- drop unnecessary '%m' in error message when the error code is
specified with SYNTHETIC_ERRNO(),
- add missing full stop at the end of log message,
- use RET_GATHER(),
- add missing ", ignoring.",
- upeercase the first letter, etc., etc...
In many of our internal functions that take a pointer + a size we have
introduced the rule that SIZE_MAX as size means: take strlen().
sd_journal_add_match() has something similar, but the special value is
0, not SIZE_MAX. This is a bit ugly, since a zero size data block is
theoretically fine. The only reason sd_journal_add_match() gets away
with using this special value is because valid matches must consist of
at least 2 chars, hence cannot be zero.
But let's make this more robust and less surprising when compared to the
rest of our code, and *also* accept SIZE_MAX to mean strlen().
No actual code changes, just some clean-up.
This means the main config file is loaded also from /run and /usr.
We should load the main config file from all the places where we load drop-ins.
I realize I had a giant blind spot: I always assumed that we load config files
from /etc, /run, /usr/local/lib, /usr/lib. But it turns out that we only used
those paths for drop-ins. For the main config file, we only looked in /etc. The
docs actually partially described this behaviour, i.e. most SYNOPSIS sections
and some parts of the text, but not others.
This is strange, because 6495361c7d was completely
bogus with the behaviour before this patch. We had a huge discussion before it
was merged, and clearly nobody noticed this. Similarly, in the previous version
of the current pull request, we had a long discussion about the appropriate
order of directories, and apparently nobody noticed that there was no order,
because only looked in one directory. So the blind spot seems to have been
shared.
Also, systemd-analyze cat-config behaved incorrectly, i.e. its behaviour matches
the new behaviour.
Possibly, in the future it'll make it easier to add support for --root.
This essentially reverts 5656cdfeea. I find it
much easier to understand what is going on when the
path-relative-to-the-search-path is passed in full, instead of being constructed
from two parts, with one of the parts being implicit in some places.
Also, we call 'systemd-analyze cat-config <path>' with <path> with the same
meaning, so this makes the internal and external APIs more consistent.
Dynamically load liblz4, libzstd and liblzma with dlopen().
This helps to reduce the size of the initrd image when these libraries
are not really needed.
let's make userspace verity signature checking optional. This adds a
dissection flag to enable the logic and patches through all our users to
enable it by default, thus effectively not changing anything from the
status quo ante. However, know we have a knob to turn this off in
certain scenarios.
We had both uid-range.h and uid-alloc-range.h. The latter now contains helpers
like {uid,gid}_is_{system,dynamic,container}(), uid_for_system_journal(), so
the existing name is outdated. I think the uid-range.[ch] should stay separate
because it has a bunch of helpers for parsing and printing of uid ranges. So
let's rename as in $subject to better reflect the contents of the file and make
the two sets of files harder to confuse.
If we're waiting for the debugger process to exit and receive SIGTERM,
propagate it to all processes in our process group, including the
debugger, so we can follow it up with a proper cleanup.
Resolves: #28772
Sometimes it makes sense to hard kill a client if we die. Let's hence
add a third FORK_DEATHSIG flag for this purpose: FORK_DEATHSIG_SIGKILL.
To make things less confusing this also renames FORK_DEATHSIG to
FORK_DEATHSIG_SIGTERM to make clear it sends SIGTERM. We already had
FORK_DEATHSIG_SIGINT, hence this makes things nicely symmetric.
A bunch of users are switched over for FORK_DEATHSIG_SIGKILL where we
know it's safe to abort things abruptly. This should make some kernel
cases more robust, since we cannot get confused by signal masks or such.
While we are at it, also fix a bunch of bugs where we didn't take
FORK_DEATHSIG_SIGINT into account in safe_fork()
Let's unconditionally drop privileges before submitting the coredump log
message.
Let's make the codepaths where we acquired a coredump and where we
didn't more alike: let's drop privs in both cases.
This is not only safer, but means that the coredump messages are always
accessible by the owner of the aborted process.
Let's not claim a process dumped core if that was disabled via resource
limits.
While we are at it, switch from stack to heap allocation for the log
message, as it includes a stack trace which can be arbitrarily large.
Fixes: #28559
We use it for more than just pipe() arrays. For example also for
socketpair(). Hence let's give it a generic name.
Also add EBADF_TRIPLET to mirror this for things like
stdin/stdout/stderr arrays, which we use a bunch of times.
This is preparation for #28891, which adds a bunch more helpers around
"struct iovec", at which point this really deserves its own .c/.h file.
The idea is that we sooner or later can consider "struct iovec" as an
entirely generic mechanism to reference some binary blob, and is the
go-to type for this purpose whenever we need one.
We usually check return value of syscalls or glibc functions by it is
negative or not, something like that `if (stat(path, &st) < 0)`.
Let's also use the same style for lseek() and friends even the type of
their return value is off_t.
Note, fseeko() returns int, instead of off_t.
This allows distros to install configuration file templates in /usr/lib/systemd
for example.
Currently we install "empty" config files in /etc/systemd/. They serve two
purposes:
- The file contains commented-out values that show the default settings.
- It is easier to edit the right file if it is already there, the user doesn't
have to type in the path correctly, and the basic file structure is already in
place so it's easier to edit.
Things that have happened since this approach was put in place:
- We started supporting drop-ins for config files, and drop-ins are the
recommended way to create local configuration overrides.
- We have systemd-analyze cat-config which takes care of iterating over
all possible locations (/etc, /run, /usr, /usr/local) and figuring out
the right file.
- Because of the first two points, systemd-analyze cat-config is much better,
because it takes care of finding all the drop-ins and figuring out the
precedence. Looking at files manually is still possible of course, but not
very convenient.
The disadvantages of the current approach with "empty" files in /etc:
- We clutter up /etc so it's harder to see what the local configuration actually is.
- If a user edits the file, package updates will not override the file (e.g.
systemd.rpm uses %config(noreplace). This means that the "documented defaults"
will become stale over time, if the user ever edits the main config file.
Thus, I think that it's reasonable to:
- Install the main config file to /usr/lib so that it serves as reference for
syntax and option names and default values and is properly updated on package
upgrades.
- Recommend to users to always use drop-ins for configuration and
systemd-analyze cat-config to view the documentation.
This setting makes this change opt-in.
Fixes#18420.
[zjs: add more text to the description]
If a process crashes within a container, try and forward the coredump to
that container. To do this, check if the crashing process is in a
different pidns, and if so, find the PID of the namespace leader. We
only proceed with forwarding if that PID belongs to a cgroup that is
descendant of another cgroup with user.delegate=1 and
user.coredump_receive=1 (i.e. Delegate=yes and CoredumpReceive=yes).
If we proceed, attach to the namespaces of the leader, and send the
coredump to systemd-coredump.socket in the container. Before this is
done, we need to translate the PID, UID, and GID, and also re-gather
procfs metadata. Translate the PID, UID, and GID to the perspective of
the container by sending an SCM_CREDENTIALS message over a socket pair
from the original systemd-coredump process, to the process forked in the
container.
If we cannot successfully forward the coredump, fallback to the current
behavior so that there is still a record of the crash on the host.
For a given PID and namespace type, this helper function gives the PID
of the leader of the namespace containing the given PID. Use this in
systemd-coredump instead of using the existing get_mount_namespace_leader.
This helper will be used again in a later commit.
For convenience, store the crashing process's UID and GID in Context (as
uid_t and gid_t, respectively), as is currently done for the PID. This
means we can just parse the UID/GID once in save_context(), and use
those values in other places.
This is just re-factoring, and is a preparation commit for container
support.
Previously, we did not check error from iovw_put(). If it fails, the
target iovw may have no iov or partial iovs from the journal importar.
So, the finalization may cause underflow and may access and free invalid
memory.
Follow-up for 946dc7c635.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_PRIVILEGE() is the value
returned by access_fd() which is not expected to return any positive
values, but let's be consistent anyway and move the ERRNO_IS_PRIVILEGE()
invocation to the branch where the return value is known to be negative.
Doesn't really matter since the two unicode symbols are supposedly
equivalent, but let's better follow the unicode recommendations to
prefer greek small letter mu, as per:
https://www.unicode.org/reports/tr25
This changes a boolean param into a proper bitflag field.
Given this only defines a single flag for now this doesn't look like
much of an improvement. But we'll add another flag shortly, where it
starts to make more sense.
