Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
If an error happened while the timeout value was being programmed, the error
was ignored and the watchdog module used the new timeout value whereas the
watchdog device was left with the previous one.
Now in cases of error, the device is now disabled and closed if it wasn't
opened already otherwise the previous timeout value is kept so the device is
still pinged at correct intervals.
Passing 0 meant "disable the watchdog although still kept it opened". However
this case didn't seem to be useful especially since PID1 closes the device if
it is passed the nul timeout.
Hence let's change the meaning of watchdog_setup(0) to match PID1's behavior
which allows to simplify the code a bit.
Hence this patch also drops enable_watchdog().
This patch changes the meaning of USEC_INFINITY value for the watchdog
module.
Previously passing this value was a NOP. It now has a special meaning: it
requests the watchdog module to read the programmed timeout value and reuse it
for pinging the device.
This is mostly useful when the watchdog is started by the firmware and there's
no way to reconfigure the timeout with a different value
afterwards. "RuntimeWatchdogSec=infinity" in system.conf can now be used rather
than putting an arbitrary value that PID1 will fail to set (even if it still
felt back to the programmed timeout).
Please note that "infinity" is not supposed to restore the default value of the
firmware. If the value is changed after booting then "infinity" would simply
reuse the current programmed value. IOW it's a NOP unless the watchdog was
previously closed and in that case it will be reopened and the last programmed
value reused.
Check if any cgroup controller is currently being used as v1, and if so don't
use cgroup unified mode. This is only checked when there is no cgroup already
mounted, and is most useful when running in a container where the host is using
a legacy or hybrid cgroup, since we can't (fully) use unified cgroup, as the
host kernel has the cgroup controllers in use by v1.
This shouldn't be needed if the container manager has pre-mounted cgroups
appropriately based on the host system cgroup setup, but we can't rely
on that always being the case.
I read the message and initially thought that there's some bug in time
subtraction. Let's make it clear that the message is about what we'll
do in the future, and not a report on how we waited up until now.
Currently ref count of bpf-program is kept in user space. However, the
kernel already implements its own ref count. Thus the ref count we keep for
bpf-program is redundant.
This PR removes ref count for bpf program as part of a task to simplify
bpf-program and remove redundancies, which will make the switch to
code-compiled BPF programs easier.
Part of #19270
This is a debugging feature. It's sometimes incredibly useful to be able
to run a second instance of homed that operates on another dir than
/home/.
Specifically, if you build homed from the source tree you can now run an
instance of it pretty reasonably directly from the build tree via:
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo SYSTEMD_HOMEWORK_PATH=$(pwd)/build/systemd-homework SYSTEMD_HOME_ROOT=/home/foo ./build/systemd-homed
And then talk to it via
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo homectl …
(you might need to tweak your dbus policy for this to work fully though)
Using kernel types __u32 is fine for headers shared by the kernel, but
if we define something in userspace and only use it in userspace, in our
own .c files, let's stick to userspace fixed-length types.
let's make sure the specified hostname is really valid before we build
an fs path from it. Just as a safety future, so that people can't trick
us with hostnames including "/../" or so.
Unfortunately fgetxattr() and flistxattr() don't work via O_PATH fds.
Let's thus add fallbacks to go via /proc/self/fd/ in these cases.
Also, let's merge all the various flavours we have here into singular
implementations that can do everything we need:
1. malloc() loop handling
2. by fd, by path, or combination (i.e. a proper openat() like API)
3. work on O_PATH
These functions are used pretty much independently of locale, i.e. the
only info relevant is whether th locale is UTF-8 or not. Hence let's
give this its own pair of .c/.h files.
The commit 6597686865 ("seccomp: don't install filters for archs that
can't use syscalls") introduced a regression where filters may not be
installed for the "native" architecture. This means that setting
SystemCallArchitectures=native for a unit effectively disables the
SystemCallFilter= and SystemCallLog= options.
Conceptually, we have two filter stages:
1. architecture used for syscall (SystemCallArchitectures=)
2. syscall + architecture combination (SystemCallFilter=)
The above commit tried to optimize the filter generation by skipping the
second level filtering when it is not required.
However, systemd will never fully block the "native" architecture using
the first level filter. This makes the code a lot simpler, as systemd
can execve() the target binary using its own architecture. And, it
should be perfectly fine as the "native" architecture will always be the
one with the most restrictive seccomp filtering.
Said differently, the bug arises because (on x86_64):
1. x86_64 is permitted by libseccomp already
2. native != x86_64
3. the loop wants to block x86_64 because the permitted set only
contains "native" (i.e. "native" != "x86_64")
4. x86_64 is marked as blocked in seccomp_local_archs
Thereby we have an inconsistency, where it is marked as blocked in the
seccomp_local_archs array but it is allowed by libseccomp. i.e. we will
skip generating filter stage 2 without having stage 1 in place.
The fix is simple, we just skip the native architecture when looping
seccomp_local_archs. This way the inconsistency cannot happen.
Lennart Poettering
Dan Streetman
Franck Bui
Zbigniew Jędrzejewski-Szmek
alexlzhu
Yu Watanabe
Frantisek Sumsal
Luca Boccassi
Iago López Galeiras
Egor
Benjamin Berg