Let's be safe, rather than sorry. This way DynamicUser=yes services can
neither take benefit of, nor create SUID/SGID binaries.
Given that DynamicUser= is a recent addition only we should be able to
get away with turning this on, even though this is strictly speaking a
binary compatibility breakage.
Quite often we have a method DoSomethingWithUnit() on the Manager object
that is the same as a function DoSomething() on a Unit object. Let's
shorten things by introducing a common function that forwards the
former to the latter, instead of writing this again and again.
let's use sd_notifyf(). Let's also stop validating the session ID here.
This is the destructor. if it contains a dash, we are already too late
here anyway.
systemd-journal-remote always wrote the boot-id of the device it was running on
to the header of its journal files. When the source had a different boot-id
(because it was generated on a different boot, or a different device), the
boot-ids in the file were inconsistent. The _BOOT_ID field was that of the
source, but the journal file header and each entry object header were that of
the device systemd-journal-remote ran on. This breaks journalctl --list-boots
on any of these files.
Set the boot-id in the header to be that of the source. This also fixes the
entry object headers.
Another fix in style of bd169c2be0.
Let's also avoid strjoina() in a loop (i.e. stack allocation). While in
this specific caseone could get away with it (since we'd immediately
afterwards leave the loop) it's still ugly, and every static checker
would be totally within its rights to complain.
Also, let's simplify things by not relying on argc, since it's redundant
anyway, and it's nicer to just treat things as NULL terminated strv
array.
Fixes: #12180
In particular, let's not use gotos that jump up, i.e. are loops. gotos
that jump down for the purpose of clean-up are cool, but using them for
loops is evil.
No change in behaviour, just some refactoring.
It's not easy to implement such a combined operation race-freely since
dropping a subvolume will drop all its contents, including any
non-directories.
Hence, let's just not support this combination for now. Which isn't much
of a loss, since we never combine these flags anyway.
Lennart Poettering