The personality() syscall returns a 32-bit value where the top three
bytes are reserved for flags that emulate historical or architectural
quirks, and only the least significant byte reflects the actual
personality we're interested in (in opinionated_personality()).
Use the newly defined mask in the corresponding test as well, otherwise
the test fails on some more "exotic" architectures that set some of the
"quirk" flags:
~# uname -m
armv7l
~# build/test-seccomp
...
/* test_lock_personality */
current personality=0x0
safe_personality(PERSONALITY_INVALID)=0x800000
Assertion '(unsigned long) safe_personality(current) == current' failed at src/test/test-seccomp.c:970, function test_lock_personality(). Aborting.
lockpersonalityseccomp terminated by signal ABRT.
Assertion 'wait_for_terminate_and_check("lockpersonalityseccomp", pid, WAIT_LOG) == EXIT_SUCCESS' failed at src/test/test-seccomp.c:996, function test_lock_personality(). Aborting.
Aborted (core dumped)
See: personality(2) and comments in sys/personality.h
This is in preparation for https://github.com/systemd/systemd/pull/30360 to be
merged in a future release. As described there:
nscd is known to be racy [1] and it was already deprecated and later dropped
in Fedora a while back [1,2]. We don't need to support obsolete stuff in
systemd, and the cache in systemd-resolved provides a better solution anyway.
[1] https://fedoraproject.org/wiki/Changes/DeprecateNSCD
[2] https://fedoraproject.org/wiki/Changes/RemoveNSCD
Note that our "support" is only the signal to flush the cache that we send at
various points. Nscd itself may still exist, dropping it is a decision to be
made in glibc.
Fixes an issue caused by ab3aed4a03 (v253).
By default, all managed interface need to be configured, and at least
one interface need to be online. Hence, offline interface should be ignored.
Fixes#29506.
systemd-cryptenroll uses the READ_FULL_FILE_CONNECT_SOCKET flag when
reading the keyfile to also allow reading it from a socket. But it also
sets the offset to 0, causing an unnecessary seek to the beginning of
the newly opened keyfile and disables socket support again, as these do
not support seeking.
Disable seeking entirely to remove the unneeded seek and restore support
for reading the keyfile from a socket again as with systemd-cryptsetup.
Also= lists units which should be enabled/disabled together with the first unit.
But userdbd is independent of homed, we shouldn't e.g. disable it even if homed
is disabled.
I tried to be conservative here, and hence in doubt I left the flag off,
but in some cases I really can't see any reason why it would make sense
to specifiy paths into API VFS, hence add it there, to lock things down
a bit.
Inspired by CVE-2024-21626, let's add a longer comment explaining why
the code really shouldn#t be moved any earlier.
Just in the hope that anyone who feels tempted to move this around maybe
actually reads the comment and reconsiders.
In various contexts it's a bit icky to allow paths below /proc/, /sys/,
/dev/ i.e. file hierarchies where API VFS are placed. Let's add a new
flag for path_simplify_and_warn() to check for this and refuse a path if
in these paths.
Enable this when parsing WorkingDirectory=.
This is inspired by CVE-2024-21626, which uses trickery around the cwd
and /proc/self/fd/.
AFAICS we are not actually vulnerable to the same issue as explained in
the CVE since we execute the WorkingDirectory= setting very late, i.e.
long after we set up the new mount namespace. But let's filter out icky
stuff better earlier than later, as extra safety precaution.
posix_spawnattr_setflags() doesn't OR the input to the current set of flags,
it overwrites them, so we are currently losing POSIX_SPAWN_SETSIGDEF.
Follow-up for: 6ecdfe7d10
We already use __VA_OPT__ in multiple places, which was introduced in
gcc 8 [0], so let's bump the baseline to reflect that. I chose gcc 8.4,
as that was the lowest 8.x version I could easily get my hands on when I
verified this (on Ubuntu Focal with the gcc-8 package).
Closes: #31191
[0] https://gcc.gnu.org/gcc-8/changes.html
This seems to be a mistake in #27279. I believe credentials should
not be made available to condition or reload tasks. In most cases
they're irrelevant from the actual job of the service. Also, currently
the first ExecCondition= or ExecReload= cannot access creds anyway,
making the incompatibility introduced negligible.
If people actually come up with valid use cases, we can always
revisit this.
Common sense says that to "try" something means "to not fail if
something turns out not to be possible", thus do not make this
combination a hard error.
The actual implementation ignores any --link-journal= setting when
--ephemeral is in effect, so the semantics are upheld.
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Felix Riemann
Luca Boccassi
Mike Yuan
Lennart Poettering
James Muir
Anders Jonsson
Ivan Shapovalov
Vladimir Stoiakin
Antonio Alvarez Feijoo
Harald Brinkmann