Let's allow users to configure the (logical) sector size of their
image. This is required when building images for a 4k sector size
disk on a 512b sector size host or vice-versa.
The systemd-growfs@.service units are currently written in full for each
file system to grow. Which is kinda pointless given that (besides an
optional ordering dep) they contain always the same definition. Let's
fix that and add a static template for this logic, that the generator
simply instantiates (and adds an ordering dep for).
This mimics how systemd-fsck@.service is handled. Similar to the wait
that for root fs there's a special instance systemd-fsck-root.service
we also add a special instance systemd-growfs-root.service for the root
fs, since it has slightly different deps.
Fixes: #20788
See: #10014
This erase_obj() machinery looks like voodoo and creates an awful lot of
noise as soon as we get back to building with -O0. We can do this in a
more simple way by introducing a struct that holds the information we
need on cleanup. When building with optimization enabled, all this gets
inlined and the eraser vanishes.
This commit adds support for attaching extra metadata to log
messages written to the journal via log.h. We keep track of a
thread local log context in log.c onto which we can push extra
metadata fields that should be logged. Once a field is no longer
relevant, it can be popped again from the log context.
On top of this, we then add macros to allow pushing extra fields
onto the log context.
LOG_CONTEXT_PUSH() will push the provided field onto the log context
and pop the last field from the log context when the current block
ends. LOG_CONTEXT_PUSH_STRV() will do the same but for all fields in
the given strv.
Using the macros is as simple as putting them anywhere inside a block
to add a field to all following log messages logged from inside that
block.
void myfunction(...) {
...
LOG_CONTEXT_PUSH("MYMETADATA=abc");
// Every journal message logged will now have the MYMETADATA=abc
// field included.
}
For convenience, there's also LOG_CONTEXT_PUSHF() to allow constructing
the field to be logged using printf() syntax.
log_context_new()/log_context_free() can be used to attach a log context
to an async operation by storing it in the associated userdata struct.
This allows passing pre-allocated buffers via compound initializers
to snprint_ok(). If snprintf_ok() is a macro, the compound initializer
block will be scoped to the macro block, if snprint_ok() is a function,
the compound initializer block will be scoped to the block from which
snprintf_ok() is called.
Commit 1b86c7c59e ("virt: make virtualization enum a named type")
made the conversion from `if (!r)` to `if (v != VIRTUALIZATION_NONE)`.
However, the initial test was meaning "if r is null", IOW "if r IS
`VIRTUALIZATION_NONE`).
The test is wrong and this can lead to false detection of the container
environment (when calling `systemctl exit`).
For example, https://gitlab.freedesktop.org/whot/libevdev/-/jobs/34207974
is calling `systemctl exit 0`, and systemd terminates with the exit code
`130`.
Fixing that typo makes `systemctl exit 0` returns `0`.
Fixes: 1b86c7c59e.
../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
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.
Daan De Meyer
Lennart Poettering
Ludwig Nussel
Jan Janssen
Siddhesh Poyarekar
Benjamin Tissoires
Luca Boccassi
Cristian Rodríguez
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Michal Sekletar
Quentin Deslandes