This is the same as json_dispatch_user_group_name() but fills in the
string as "const char*" to the JSON field. Or in other words, it's what
sd_json_dispatch_const_string() is to sd_json_dispatch_string().
Note this drops the SD_JSON_STRICT flags from various dispatch tables
for these fields, and replaces this by SD_JSON_RELAX, i.e. the opposite
behaviour. As #34558 correctly suggests we should validate user names
in lookup functions using the lax rules, rather than the strict ones,
since clients not knowing the rules might ask us for arbitrary
resolution.
(SD_JSON_RELAX internally translates to valid_user_group_name() with the
VALID_USER_RELAX flag).
See: #34558
This tries to get rid of most manual sigprocmask() changes, in favour
of:
1. The SD_EVENT_SIGNAL_PROCMASK flag to sd_event_add_signal()
2. The sd_event_set_signal_exit() call for handling SIGTERM/SIGINT
3. Move masking of SIGWINCH into ptyfwd, out of nspawn/vmspawn/run
And while we are at it get rid of a bunch of event source fields whose
lifetime is bound to the sd_event object they belong to anyway, and make
use of the "floating" event source feature of sd-event instead.
These operations might require slow I/O, and thus might block PID1's main
loop for an undeterminated amount of time. Instead of performing them
inline, fork a worker process and stash away the D-Bus message, and reply
once we get a SIGCHILD indicating they have completed. That way we don't
break compatibility and callers can continue to rely on the fact that when
they get the method reply the operation either succeeded or failed.
To keep backward compatibility, unlike reload control processes, these
are ran inside init.scope and not the target cgroup. Unlike ExecReload,
this is under our control and is not defined by the unit. This is necessary
because previously the operation also wasn't ran from the target cgroup,
so suddenly forking a copy-on-write copy of pid1 into the target cgroup
will make memory usage spike, and if there is a MemoryMax= or MemoryHigh=
set and the cgroup is already close to the limit, it will cause an OOM
kill, where previously it would have worked fine.
It's time. sd-json was already done earlier in this cycle, let's now
make sd-varlink public too.
This is mostly just a search/replace job of epical proportions.
I left some functions internal (mostly IDL handling), and I turned some
static inline calls into regular calls.
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.
We announced the plan to drop nscd in d44934f378.
[1] https://fedoraproject.org/wiki/Changes/DeprecateNSCD
[2] https://fedoraproject.org/wiki/Changes/RemoveNSCD
The option is kept as a stub without any effect to make the transition easier.
On dbus we have two apis: one for registering a new machne when the
client already has a cgroup (RegisterMachine()) and one where it doesn't
and machined shall create it (CreateMachine()).
Let's add the same for the varlink api. To simplify things we just
implement it via a boolean flag to the existign RegisterMachine()
varlink call, since the differences are mostly minor otherwise.
Now that we have a concept of unprivileged VMs and containers, let's
allow unprivileged clients to register with machined too – subject to
Polkit permissions.
If we have a pidfd, we might as well track the machine's leader PID's
lifetime, and enqueue the machine for a GC run.
(This is similar to what we are already doing for logind's session
leaders)
One major omission in machine's logic so far was that the GC was only
run at startup and on the check-idle timeout, which is really slow.
Let's make this more like the GC logic in homed or logind: make sure we
run it in a close-by event loop cycle.
The flag is fairly generic these days and just selects a slightly
stricter validation, with details depending on the selected dispatch
function. Hence, let's give it more precise name, in particular one that
mirrors the SD_JSON_RELAXED flag nicely (which does the opposite:
relaxes parsing)
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
The functions more or less do the same thing. Merge them.
This makes json_dispatch_path() the common resulting implementation. it
learnt:
1. Will reset the path to NULL if specified as null in JSON
2. Depending on the JSON_SAFE flag will insist on normalized path or not
With this the two implementations are identical, except for the
differences now toggable via JSON_SAFE flag
if machined exits while a machine is still running, we'll issue the
UnrefUnit() call on the unit. This quite likely will fail if during
shutdown the bus connection is already down. But that's no reason to
warn at all, since the ref count will implicitly be dropped if our side
disappears from the bus. Hence, downgrade to LOG_DEBUG in case of
connection problems.
Fixes a bug introduced by 1ddb263d21.
Note, this requires the previous two commits, and cannot backport without them.
Note, before the previous commit, the use-after-free could be triggered
only by Rename() DBus method, and could not by RenameImage(), as we did not
cache Image object when RenameImage() method is called. And machinectl
always uses RenameImage(). Hence, the issue could be triggered only when
Rename() DBus method is explicitly called by e.g. busctl.
With the previous commit, the Image object passed to the function is
always cached. Hence, the issue could be triggered even with machinectl
command, and this fix is important.
Previously, Image objects were only cached when reading properties or
methods in the org.freedesktop.machine1.Image interface are called.
This makes that, when a method in the main interface (org.freedesktop.machine1)
for an image is called, also acquire the Image object from the cache,
and if not cached, create Image object and put into the cache, like we
do for org.freedesktop.machine1.Image.
Otherwise, if some properties of an image are updated by methods in the main
interface, e.g. MarkImageReadOnly(), the changes do not applied to the cached
Image object, and subsequent read of proerties through the interface for the
image, e.g. ReadOnly property, may provide outdated values.
Follow-up for 1ddb263d21.
Fixes#32888.
Daan De Meyer
Ivan Kruglov
Lennart Poettering
Mike Yuan
Yu Watanabe
Luca Boccassi
Zbigniew Jędrzejewski-Szmek