So far the idea was that the default is 'auto', and if appropriate, the
distribution will create /var/log/journal/ to tell journald to use persistent
mode. This doesn't work well with factory resets, because after a factory reset
obviously /var/log is gone. That old default was useful when journald was new
and people were reluctant to enable persistent mode and instead relied on
rsyslog and such for the persistent storage. But nowadays that is rarer, and
anyway various features like user journals only work with persistent storage,
so we want people to enable this by default. Add an option to flip the default
and distributions can opt in. The default default value remains unchanged.
(I also tested using tmpfiles to instead change this, since we already set
access mode for /var/log/journal through tmpfiles. Unfortunately, tmpfiles runs
too late, after journald has already started, so if tmpfiles creates the
directory, it'll only be used after a reboot. This probably could be made to
work by adding a new service to flush the journal, but that becomes complicated
and we lose the main advantage of simplicity.)
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1387796.
- musl does not support gshadow, and does not provide gshadow.h,
- musl does not support nss, and does not provide nss.h which is necessary
for each nss modules,
- musl does not provide NI_IDN.
glibc sets it when _GNU_SOURCE is defined, however, musl does not.
Let's explicitly define it to make getdents64() and struct dirent64
available even when building with musl.
A --empower session is effectively root without being UID 0, so it
doesn't make sense to enforce polkit authentication in those. Let's
add the empower group, add --empower sessions to that group and ship
a polkit rule to skip authentication for all users in the empower
group.
(As a side-effect this will also allow users to add themselves to this
group outside of 'run0 --empower' to mimick NOPASSWD from sudo)
- use loop for checking existence of functions,
- rename HAVE_LIBARCHIVE_XYZ -> HAVE_ARCHIVE_XYZ to make them match with
the function name,
- do not conditionally include user-util.h in libarchive-util.h,
- sort library function symbols.
We'd like to measure various additional things into PCRs, but all
available ones to the OS are already used for various purposes. Hence,
let's introduce a new concept of "NV Index based PCRs", i.e. let's use
TPM2 nv indexes of type TPM2_NT_EXTEND that mostly behave like real
PCRs, but which we can allocate relatively freely from the nv index
space. Let's call these "fake" PCRs "NvPCRs".
My original intention was to get a fixed NV index range assigned from
the TCG, either for Linux or for systemd as a project, but this stalled
with no further updates from the TCG for more than a year and a half
now. I was told an NV index range to use though, even if it never was
officially assigned, hence this PR uses this by default. But the range
is configurable at build time, on purpose, so that downstreams have some
flexibility to change this if they want. To abstract the actual nvindex
number away we introduce a naming concept, so that nvindexes are
referenced by name string rather than number.
NvPCRs are defined in little JSON snippets in /usr/lib/nvpcr/*.nvpcr,
that match up index number and name, as well as pick a hash algorithm.
There's one complication: these nvindex (like any nvindex) can be
deleted by anyone with access to the TPM, and then be recreated. This
could be used to reset the NvPCRs to zero during runtime, which defeats
the whole point of them. Our way out: we measure a secret as first thing
after creation into the NvPCRs. (Or actually, we measure a per-NvPCR
secret we derive from a system secret via an HMAC of the NvPCR name) and
the nvindex handle). This "anchoring" secret is stored in /run/ +
/var/lib/ + ESP/XBOOTLDR (the latter encrypted as credential, locked to
the TPM), to make it available at the whole runtime of the OS.
The functions crypt_set_metadata_size() and friends are supported since
libcryptsetup-2.0.
This also merges checks for functions used for supporting libcryptsetup
plugins with others.
Moreover, check existence of one more function (crypt_logf) that is used in
libcryptsetup plugins.
Let's not leak details from src/shared and src/libsystemd into
src/basic, even though you can't actually do anything useful with
just forward declarations from src/shared.
The sd-forward.h header is put in src/libsystemd/sd-common as we
don't have a directory for shared internal headers for libsystemd
yet.
Let's also rename forward.h to basic-forward.h to keep things
self-explanatory.
Let's use libarchive consistently everywhere, both for tarring and
untarring.
Note that there's an existing test case that validates untarring. Now,
it will validate libarchive rather than gnu tar.
Split out of #38728
This reverts commit e1e1ef09f9.
This change was misguided. The warning is enough during development and will
get fixed, but turning this into a hard failure just makes WIP harder. Also, a
hard error increases the likelyhood of a build failure in scenarios where
somebody is disabling components (as seen e.g. in
ba8801a076). We already are not very good at
keeping our codebase compile correctly as it ages, because of changes in
compilers and dependencies, and we should not go out of our way to increase the
probability of failure. Such scenarios are painful for downstream builds.
We dropped support for split-usr a while ago, which means that the programs
will be in /usr/sbin, which actually may be the same as /usr/bin on merged-bin
systems. So the whole checking is mostly pointless in the usual case. OTOH, on
Nix the paths will be totally different and need to be set through the option
anyway. So save time during builds by using the "fallback" path unless the
option is specified.
This avoid some busywork during the slow serial build phase.
This way we have can expose identical behaviour everywhere, can make use
of our atomic replacement calls, and openat() logic, and later apply
additional tracks while unpacking, such as putting limits on UID ranges
and similar.
Most of those were dropped in 7d247d3cb8. I left
behind the few cases where the 'output' name was different from the target name.
But we actually don't need those either, so get rid of those. (And one case
where I missed the name argument.)
No functional change, except that e.g. 'ninja -C build update-man-rules-impl'
doesn't work, but I hope nobody was using that.
Those were added before 0.61 which is our minimum version.
Dots were dropped from the end of some messages. Most messages did not have the
trailing dot.
0.63 added support for multi-line f-strings. We can't use those yet.
It helps nobody to break compatibility for a missing definition
for printing an error.
Just add the missing definition if not present, as it is already
done for thousands of others from the kernel, glibc, etc.
This partially reverts commit d8b60944f5.
This is also preparation for the installer later, split out of #38764.
It makes the experience a lot nicer if our nice little tools aren't
constantly interrupted by log spew from the kernel.
Fixes: #34448
For "wizard" style interactive tools it's very annoying if they are
interrupted by kernel log output or PID1's status output. let's add some
infra to disable this temporarily. I decided to implement this as an IPC
service so that we can make this robust: if the client request the
muting dies we can automatically unmute again.
This is hence a tiny varlink service, but it can also be started
directly from the cmdline.
I initially didn't think it would be worth doing this, but I changed my
mind. People out there quite successfully build systemd without ACL
support, and that suggests life without it is quite possible. Moreover
we only use it as very specific places:
1. in udev/logind for "uaccess" mgmt
2. in tmpfiles to implement explicitly configured acl changes
3. in journald/coredump/pstore to manage access to unpriv users
4. in pid1 to manage access to credential files
5. when shifting UIDs of container trees
I specific container environments it should be entirely fine to live without all
of these, hence let's pull this in on demand only.
Major distributions already have libfido2 >= 1.12.0. Let's bump the
required minimum version to 1.5.0, which provides FIDO_ERR_UV_BLOCKED.
Note, libfido2 1.5.0 was released on 2020-09-01.
See also #38608.
Major distributions already have libfido2 >= 1.12.0.
Let's bump the required minimum version to 1.5.0, which provides
FIDO_ERR_UV_BLOCKED.
Note, libfido2 1.5.0 was released on 2020-09-01.
See also #38608.
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able to have
it in /nix/store too like the other util-linux tools).
Given that `unmerged-usr` support was dropped in 255 I think this is a
safe change?
There is a botched arm64 linker transition going on, where a new feature
is enabled (GCS) and the linker fails the build unless all object files
being linked are built with the new specific feature. This was enabled
in the toolchain (GCC 15) _before_ all libraries were rebuilt, including
glibc, so everything fails. The toolchain maintainers declined to fix it
and instead say that this is a useless warning to have, and to just
disable it and ignore it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110461
> systemd fails to build from source on arm64 if built with GCC-15, currently in
> experimental.
>
> GCC-15 includes support for an arm64 security feature called Guarded Control
> Stack (GCS). To help with GCS adoption, the linker warns about shared libraries
> built without GCS. For example:
>
> /usr/lib/gcc/aarch64-linux-gnu/15/../../../aarch64-linux-gnu/libncursesw.so.6:
> warning: GCS is required by -z gcs, but this shared library lacks the necessary property note.
> The dynamic loader might not enable GCS or refuse to load the program unless
> all the shared library dependencies have the GCS marking.
>
> The warning is harmless, and can be ignored. However, systemd is built with
> --fatal-warnings, and for this reason will fail to build on arm64 once GCC-15
> becomes the default compiler in Debian.
[585/3230] Linking target src/core/libsystemd-core-258.so
FAILED: src/core/libsystemd-core-258.so
gcc -o src/core/libsystemd-core-258.so -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,-soname,libsystemd-core-258.so -Wl,--whole-archive -Wl,--start-group src/core/libsystemd-core-258.a -Wl,--no-whole-archive -fstack-protector -Wl,-z,relro -specs=/usr/share/debhelper/dh_package_notes/debian-package-notes.specs -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/work/src=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -O0 -g -Og -Wdate-time '-Wl,-rpath,$ORIGIN/../shared' src/shared/libsystemd-shared-258.so -shared -Wl,--version-script=/work/src/src/shared/libshared.sym /usr/lib/aarch64-linux-gnu/libacl.so /usr/lib/aarch64-linux-gnu/libaudit.so /usr/lib/aarch64-linux-gnu/libblkid.so -ldl -lm /usr/lib/aarch64-linux-gnu/libmount.so -lrt /usr/lib/aarch64-linux-gnu/libseccomp.so /usr/lib/aarch64-linux-gnu/libselinux.so -Wl,--end-group -pthread -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--gc-sections -Wl,--warn-common
src/shared/libsystemd-shared-258.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libacl.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libaudit.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libblkid.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libm.so.6: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libmvec.so.1: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libmount.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libseccomp.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libselinux.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libc.so.6: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/ld-linux-aarch64.so.1: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
collect2: error: ld returned 1 exit status
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able
to have it in /nix/store too like the other util-linux tools).
bpf_loop() and bpf_strncmp(), used by sysctl-monitor, were introduced
in libbpf 0.7, so skip the module if using an older version
Follow-up for 6d9ef22acd
We went back and forth between 'prog.sh', files('prog.sh'), and
find_program('prog.sh'). We want to use files() or find_program() so that we
get a good error message if the file is missing. Behaviour of meson changed
over time, and in the past not all forms could be used in all places. For
example 0f4c4f3824 added find_program() in many
places to avoid repeated messages. But it seems that all recent meson versions
work fine with files().
find_program prints silly messages:
Program tools/make-man-index.py found: YES
(/home/zbyszek/src/systemd/tools/make-man-index.py)
Program tools/meson-render-jinja2.py found: YES
(/home/zbyszek/src/systemd/tools/meson-render-jinja2.py)
...
We know that those files will be found, they are part of the git checkout.
With files() this is gone and the meson output is easier to read.
On 64-bit POWER, there are multiple versions of the ELF ABI in use.
- little-endian powerpc64 is ELFv2
- big-endian powerpc64 is
- ELFv2 when using musl
- either ELFv1 or ELFv2 when using glibc
Previously, the BPF build was hard-coding `-D_CALL_ELF=2`, which is
ELFv2. This makes the build fail on ELFv1, similarly to the original
issue that necessitated the addition of this flag on powerpc64le.
To fix this:
1. Use ELFv1 as the default (when `_CALL_ELF` is not defined, this is
the assumption that should be made about the ABI version).
2. Check if the C compiler has `_CALL_ELF` defined, and if it does,
override the default with that.
That's technically not the *correct* compiler in this situation, but I'm
unsure how to get a compiler object for the BPF one from Meson to do the
`*_define('_CALL_ELF')` checks with, and they *should* both be targeting
the same ABI version anyway.
3. Add the ABI version to the `_CALL_ELF` definition for the BPF
compiler flags.
This makes a BPF-enabled build succeed on powerpc64 w/ ELFv1 glibc.
