This is a new syscall provided by the kernel used to implement faster
uprobes. It's not supposed to be called by userspace, but only by kernel
generated uprobe code.
It should be fine to allow this, as the kernel authenticates the
invocation itself, and we shouldn't break compat with things.
Note that this allowlisting is not sufficient to make ureprobe() work.
libseccomp must be tought the syscall too, but this can happen
independently.
Fixes: #34615
We do half a validation currently ourselves (i.e. check the header fits
into the rest of the data), and leave the other half to the
caller (i.e. check the table fits into the rest of the data).
get_smbios_table() is changed to accept the minimum object size and
validates it before returning a table.
Based on a discussion with @anonymix007.
Let's more clearly indicate that we failed to set up the server
which forwards messages from the remote client to the local bus
instead of logging a generic bus client message.
Let's move this check to bus_connect_transport_systemd() so that
bus_connect_system_systemd() will only ever connect to the manager
private manager bus instance and fail otherwise.
We have various callsites that explicitly need the manager bus and
won't work with the system bus, like daemon-reexec and friends which
can't properly wait until the operation has finished unless using the
manager bus.
If we silently fall back to the system bus for these operations, we
can end up with rather hard to debug issues so let's remove the fallback
as it was added back in 2013 in a6aa89122d
without a clear explanation of why it was needed (I expect as a fallback
if kdbus wasn't available but that's not a thing anymore these days).
We might also fail to connect to the private manager bus itself if
the daemon-reexec is still ongoing, so let's handle that as well by
retrying on ECONNREFUSED.
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.
Some structures we'll use in various varlink interfaces, move them to a
common .c/.h file. For now this is only the dual timestamp object, but
there will be more soon.
Let's always use systemctl reload to reexec and reload user managers
now that it always implies a reexec. This moves all the job management
logic to pid 1 instead of bash and reduces the complexity of the logic
as we remove systemd-run, pam and systemd-stdio-bridge from the equation.
This field indicates whether READY=1 has been sent to
the service manager/supervisor. Whenever we reload/reexec/soft-reboot,
manager_send_reloading() always resets it to false first,
so that READY=1 is sent after reloading finishes. Hence
we utterly get "false" at all times. Kill it.
This effectively reverts 37d15cd132.
The offending commit wrongly assumed that the second READY=1
notification is for system scope only, but it also serves the purpose
of flushing out previous STATUS= containing user unit job status.
- 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 commit includes adding introduce manager_get_machine_by_pidref() as a replacement for manager_get_machine_by_pid()
and moving surrounding code to utilise PidRef.
anonymix007
Lennart Poettering
Daan De Meyer
Mike Yuan
Yu Watanabe
Jörg Behrmann
Ivan Kruglov
Darsey Litzenberger