So far, at the one place we sent a PID over Varlink we did so as a
simple numeric pid_t value. That's of course is racy, since classic PIDs
are recycled too eagerly.
Let's address that, by passing around JSON objects distantly resembling our
PidRef structure. Note that this JSON object does *not* contain the
pidfd, however, but just the pidfd inode number if known.
I originally planned to include the pidfd in some direct form, but I
figured that's not really the best idea, since we always need a
side-channel of some form for that (i.e. AF_UNIX/SCM_RIGHTS), but we
should be able to report about PIDs even without that.
Moreover, while sending the pid number and pidfd id around should always
be OK to do, it's a lot more problematic to always send a pidfd around,
since that implies that fd passing is on and it is OK to install fds
remotely in some IPC peers fd table. For example, when doing a wild dump
of service manager service state we really shouldn't end up with a bunch
of fds installed in our client's fd table.
Hence, all in all I think it is cleaner to define a structure carrying
pid number and pidfd inode id, wich is passed directly as JSON. And then
optionally, in a separate field also pass around a pidfd where it makes
sense.
Note that sending around pidfds is not that beneficial anymore if we
have the pidfd inode id, because we can always securely and reliably get
a pidfd back from a pair of pid + inode id: first we do pidfd_open() on
the pid, and then we check if it is really the right one by comparing
.st_ino after fstat().
This logic is implemented gracefully: if for some reason pidfd/pidfd
inode nrs are not available (too old kernel), we'll fall back to plain
PID numbers.
The dispatching logic knows two distinct levels of validation of the
provided PID data: if SD_JSON_STRICT is specified we'll acquire a pidfd
for the PID, thus verifying it currently exists and failing if it
doesn't. If the flag is not set, well just store the provided info
as-is, will try to acquire a pidfd for it, but not fail if we cannot.
Both modes are important in different contexts.
Also note that in addition to the pidfd inode nr we always store the
current boot ID of the system in the JSON object, since only the
combination of pidfd inode nr and boot ID of the system really is a
world-wide unique reference to a process.
When dispatching a JSON pid field we operate somewhat gracefully: we
either support the triplet structure of pid, pid inode nr, boot id, or
we accept a simple classic UNIX pid.
- use uint8_t, uint16_t, and so on, rather than unsigned char, unsigned
short, and so on, respectively,
- rename output parameters to ret or ret_xyz,
- add several missing assertions.
This is the only place where xdg_user_dir() is needed and
makes sense. All other invocations have been replaced with
user_search_dirs() - see previous commits for details.
* Rename user_dirs() -> user_unit_search_dirs() and port to
user_search_dirs()
* Use STRV_IFNOTNULL to guard paths that could be NULL,
assert otherwise
xdg_user_dirs() doesn't seem well-organized currently.
In all other xdg_user_*() funcs we assume /etc/xdg/systemd
to be a symlink to /etc/systemd/, hence it is the odd one out.
Also, when the relevant envvar is unset, it only returns
the global search dirs.
sd_path_lookup() actually covers this nicely with SD_PATH_SEARCH_*,
where the combined search paths (from user home and system) are used.
Therefore, let's introduce a wrapper for that, and deprecate xdg_user_dirs()
(would be removed in later commits).
Note that -ENXIO reported by xdg_user_config_dir() is now properly
propagated rather than ignored, as unlike XDG_RUNTIME_DIR, XDG_CONFIG_HOME
has a default value hence ENXIO is not really expected.
Let's mark functions that accept the 'more' flag explicitly for that,
and validate for this explicitly.
This is preparation for
https://github.com/varlink/varlink.github.io/issues/26, if we get that
one day. Let's make sure that from day #1 we have this info available
even if we don't generate this in the IDL for now.
Also enables the two flags for all interfaces we export that use the
logic.
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
With many fds the global windows count generally exceeds the
minimum. This results in always reusing the unused entry if
there is one, which becomes a sort of degenerate case where we're
just constantly unmapping->mapping.
Instead let's try always have at least several unused windows on
the unused list before we resort to churning through it.
Fixes#34516
Yu Watanabe
Lennart Poettering
Ivan Kruglov
Luca Boccassi
Mike Yuan
Vito Caputo
Daan De Meyer