IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
bpf_current_task_under_cgroup() returns 1 if the task is under the
specified cgroup, 0 if not, negative if an error happens.
Differentiate the 1 and -1 cases, and report to userspace when we got
and error.
An error like this is mostly unlikely, the only common one is that the
userspace doesn't populate the map, and the call returns -EAGAIN.
Tested by mocking the return value of bpf_current_task_under_cgroup():
Enumeration completed
enp1s0f0np0: Configuring with /etc/systemd/network/20-test.network.
Sysctl monitor BPF returned error: Link number out of range
Sysctl monitor BPF returned error: No CSI structure available
Sysctl monitor BPF returned error: Invalid exchange
Sysctl monitor BPF returned error: Exchange full
Sysctl monitor BPF returned error: Invalid request code
Sysctl monitor BPF returned error: Unknown error 58
Sysctl monitor BPF returned error: Device not a stream
Sysctl monitor BPF returned error: Timer expired
Sysctl monitor BPF returned error: Machine is not on the network
Sysctl monitor BPF returned error: Object is remote
Sysctl monitor BPF returned error: Advertise error
- make it accept an empty string,
- use config_parse_in_addr_prefix(),
- move null address checker to address_section_verify().
No functional change, just refactoring.
Previously, the below was refused and the IPv6 address would not assigned.
===
[Address]
Address=2001:db8:0:f101::15/64
Broadcast=192.168.0.255
===
However, in the following case, networkd warned about the broadcast
address would be ignored, and the IPv6 address would be configured.
===
[Address]
Broadcast=192.168.0.255
Address=2001:db8:0:f101::15/64
===
Also, this makes the settings parsed independently, and the
inconsistency will be checked in the section verifier.
No functional change, just refactoring.
Follow-up for 3543456f84
I don't think list is particularly useful here. The passed fds are
constant for the lifetime of service, and with this commit we track
the number of extra fds in a dedicated var anyway.
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.
When building unprivileged, the testuser home directory ends up
owned by root:root because mkosi can't chown directories to other
owners when running unprivileged. So let's fix up the testuser
ownership on first boot with tmpfiles instead.
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.
Add a note to the service-file naming scheme that reminds developers
that those names might be aliases. Hence, when parsing such unit names,
the entire name-array of a unit must be parsed, rather than just the
unit ID.
The service-name of existing applications might be already part of their
API. Hence, not all applications can switch the service ID to this new
naming scheme, but can provide suitable aliases. Document this behavior.
