../src/basic/cgroup-util.c: In function ‘skip_session’:
../src/basic/cgroup-util.c:1241:32: error: incompatible types when returning type ‘_Bool’ but ‘const char *’ was expected
1241 | return false;
We never use the return value, and it's confusing and kinda pointless
what we return there.
Hence drop it.
Originally noticed by: tristone13th <tristone13th@outlook.com>
Alternative to: #25810
This changes the definition from enpty_to_null() so that we are still
typesafe (i.e. only accept strings) but do not drop (or add) any const
to the returned string that wasn't also on the input.
Inspired by: 3196e2996f
CVE-2022-4415: systemd: coredump not respecting fs.suid_dumpable kernel setting
Affects systemd >= 247 with libacl support enabled.
This is a merge of https://github.com/systemd/systemd-security/pull/12/.
I'm doing the merge locally because github doesn't support merging directly
from systemd/systemd-security to systemd/systemd.
Process renaming happens very seldomly so we are able to afford proper
permission check, i.e. actually check for CAP_SYS_RESOURCE capability
instead of euid.
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
$TERM would generally be set if we're connected to a proper graphical terminal
emulator. In all other cases, in particular if $TERM is not set, we almost
certainly are not connected to something that can output emojis. In particular
the text console is unlikely to ever do it correctly.
So let's invert the check, and only write emojis if $TERM is set.
Fixes#25521.
If the flag is set, we mount /tmp/ in a way that is suitable for generators and
other quick jobs.
Unfortunately I had to move some code from shared/mount-util.c to
basic/mountpoint-util.c. The functions that are moved are very thin wrappers
around mount(2), so this doesn't actually change much in the code split between
libbasic and libshared.
Implications for the host would be weird if a private mount namespace is not
used, so assert on FORK_NEW_MOUNTNS when the flag is used.
systemd uses malloc_usable_size() everywhere to use memory blocks
obtained through malloc, but that is abuse since the
malloc_usable_size() interface isn't meant for this kind of use, it is
for diagnostics only. This is also why systemd behaviour is flaky when
built with _FORTIFY_SOURCE.
One way to make this more standard (and hence safer) is to, at every
malloc_usable_size() call, also 'reallocate' the block so that the
compiler can see the larger size. This is done through a dummy
reallocator whose only purpose is to tell the compiler about the larger
usable size, it doesn't do any actual reallocation.
Florian Weimer pointed out that this doesn't solve the problem of an
allocator potentially growing usable size at will, which will break the
implicit assumption in systemd use that the value returned remains
constant as long as the object is valid. The safest way to fix that is
for systemd to step away from using malloc_usable_size() like this.
Resolves#22801.
RUN_WITH_UMASK was initially conceived for spawning externals progs with the
umask set. But nowadays we use it various syscalls and stuff that doesn't "run"
anything, so the "RUN_" prefix has outlived its usefulness.
- add missing assertions,
- use size_t for buffser size or memory index,
- handle empty input more gracefully,
- return the length or the result string,
- fix off-by-one issue when the prefix is already long enough.
Let's allow using this in code shared between userspace and EFI mode.
Also, don't implement these functions via endianness conversions given
we don't actually want to convert endianess here.
When the user starts a program which elevates its permissions via setuid,
setgid, or capabilities set on the file, it may access additional information
which would then be visible in the coredump. We shouldn't make the the coredump
visible to the user in such cases.
Reported-by: Matthias Gerstner <mgerstner@suse.de>
This reads the /proc/<pid>/auxv file and attaches it to the process metadata as
PROC_AUXV. Before the coredump is submitted, it is parsed and if either
at_secure was set (which the kernel will do for processes that are setuid,
setgid, or setcap), or if the effective uid/gid don't match uid/gid, the file
is not made accessible to the user. If we can't access this data, we assume the
file should not be made accessible either. In principle we could also access
the auxv data from a note in the core file, but that is much more complex and
it seems better to use the stand-alone file that is provided by the kernel.
Attaching auxv is both convient for this patch (because this way it's passed
between the stages along with other fields), but I think it makes sense to save
it in general.
We use the information early in the core file to figure out if the program was
32-bit or 64-bit and its endianness. This way we don't need heuristics to guess
whether the format of the auxv structure. This test might reject some cases on
fringe architecutes. But the impact would be limited: we just won't grant the
user permissions to view the coredump file. If people report that we're missing
some cases, we can always enhance this to support more architectures.
I tested auxv parsing on amd64, 32-bit program on amd64, arm64, arm32, and
ppc64el, but not the whole coredump handling.
Previously, chase_symlinks() always returned an absolute path, which
changed after 5bc244aaa9. This commit
fixes chase_symlinks() so it returns absolute paths all the time again.
