We had both uid-range.h and uid-alloc-range.h. The latter now contains helpers
like {uid,gid}_is_{system,dynamic,container}(), uid_for_system_journal(), so
the existing name is outdated. I think the uid-range.[ch] should stay separate
because it has a bunch of helpers for parsing and printing of uid ranges. So
let's rename as in $subject to better reflect the contents of the file and make
the two sets of files harder to confuse.
We don't "uncapitalize" parts of an already-capitalized name when concatenating
words. In particular, we had UidRange in basic/uid-range.h and UGIDAllocationRange
in basic/uid-alloc-range.h, which is annoying.
To get the CPUID with EAX=7, we need explicitly set 0 to ECX.
From Intel® Architecture Instruction Set Extensions Programming
Reference and Related Specifications,
===
Leaf 07H output depends on the initial value in ECX.
If ECX contains an invalid sub leaf index, EAX/EBX/ECX/EDX return 0
===
Fixes#30822.
This patch adds a new parameter to parse_ip_port_range, giving callers
the option to allow ranges to have their min be 0 instead of 1.
This is then used by parse_ip_ports_token, intern used by
parse_socket_bind_item to allow port 0 when restricting bind system
calls with SocketBindDeny / SocketBindAllow.
With this, users running server software written using the golang
standard library will be able to effectively sandbox their software,
albeit with a small loss in security protections by allowing the
process to bind on a random port in the
/proc/sys/net/ipv4/ip_local_port_range.
This avoids the ({}) that IOVEC_MAKE_STRING() so far used and might
cause a memory corruption if the parameter passed in is itself allocated
via a compount initialized array or so.
Also, this makes sure both IOVEC_MAKE_STRING() and IOVEC_MAKE() accept
'const' parameters without this causing a compiler warning.
statx_timestamp is, for all intents and purposes, the same as a struct
timespec. So, we can trivially convert it and call timespec_load on it.
This commit adds helper functions that do just that.
The current check checks for n_sigbus_queue
being greater than or equal to SIGBUS_QUEUE_MAX,
when it should be just greater than as
n_sigbus_queue being SIGBUS_QUEUE_MAX indicates
that the queue is full, but not overflowed.
Distributions apparently only compile a subset of TPM2 drivers into the
kernel. For those not compiled it but provided as kmod we need a
synchronization point: we must wait before the first TPM2 interaction
until the driver is available and accessible.
This adds a tpm2.target unit as such a synchronization point. It's
ordered after /dev/tpmrm0, and is pulled in by a generator whenever we
detect that the kernel reported a TPM2 to exist but we have no device
for it yet.
This should solve the issue, but might create problems: if there are TPM
devices supported by firmware that we don't have Linux drivers for we'll
hang for a bit. Hence let's add a kernel cmdline switch to disable (or
alternatively force) this logic.
Fixes: #30164
This combines safe_fork() with pidref_set_pid().
Eventually we really should switch this to use CLONE_PIDFD, but as that
is not wrapped by glibc yet, it's hard. But this is not crucial anyway,
as a child we just forked off can always safely be referenced also by
PID, given the reaping is under our own control.
A simple test case is added in a follow-up commit.
Triggering assert_return() should be a bug in general, and we should
really fix that. But, previously, it is hard to notice such bug, as
it was not critical.
This is for making CI or our testing environment fail if we unexpectedly
trigger assert_return(). So, hopefully we can easily find such bugs.
