We require at least crypt_r() exists, and it is provided since glibc-2.0
(and dropped in glibc-2.39) or by libxcrypt, and the function is
provided in crypt.h regardless it is provided by glibc or libxcrypt.
Hence, we cannot fallback to unistd.h.
This makes the condition about crypt.h more strict, and stop compilation
earlier when crypt.h does not exist.
Allow for mDNS service/domain/types browsing.
A client can connect to the backend via varlink and receive updates as
the requested service becomes available.
The interval between the first two queries MUST be at least one second,
the intervals between successive queries MUST increase by at least a
factor of two.
When the interval between queries reaches or exceeds 60 minutes, a
querier MAY cap the interval to a maximum of 60 minutes, and perform
subsequent queries at a steady-state rate of one query per hour.
Cache maintenance performed by issuing queries at 80, 85, 90, 95% of the
TTL, and updating/removing the records depending on replies.
TODO:
Improve the DNS transaction logic when multiple clients subscribe to the
same service, ensuring that continuous queries are optimized.
<!-- devel-freezer =
{"comment-id":"1625154850","freezing-tag":"v256-rc2"} -->
Allow for mDNS service/domain/types browsing.
A client can connect to the backend via varlink and receive updates as the
requested service becomes available.
The interval between the first two queries MUST be at least one second,
the intervals between successive queries MUST increase by at least a factor of two.
When the interval between queries reaches or exceeds 60 minutes, a querier MAY cap
the interval to a maximum of 60 minutes, and perform subsequent queries at a
steady-state rate of one query per hour.
Delete expired cache entries one second after goodbye packet received
as per RFC6762 Section 10.1
Cache maintenance:
The querier should plan to issue a query at 80% of the record lifetime, and
then if no answer is received, at 85%, 90%, and 95%.
If an answer is received, then the remaining TTL is reset to the value given
in the answer, and this process repeats for as long as the Multicast DNS querier
has an ongoing interest in the record.
If no answer is received after four queries, the record is deleted when it
reaches 100% of its lifetime.
TODO:
Improve the DNS transaction logic when multiple clients subscribe to
the same service, ensuring that continuous queries are optimized.
Co-authored-by: Vishwanath Chandapur <vishwanath.chandapur@philips.com>
Since kernel 4.18 BTRFS_IOC_GET_SUBVOL_INFO exists to query subvolume
metadata without privs. This is much better than the manual approach
with finding objects in the fs tree (which is priv). Let's use it, and
drop the old code (since 4.18 is older than our baseline).
It turns out checking sysfs is not 100% reliable to figure out whether
the firmware had TPM2 support enabled or not. For example with EDK2 arm64, the
default upstream build config bundles TPM2 support with SecureBoot support,
so if the latter is disabled, TPM2 is also unavailable. But still, the ACPI
TPM2 table is created just as if it was enabled. So /sys/firmware/acpi/tables/TPM2
exists and looks correct, but there are no measurements, neither the firmware
nor the loader/stub can do them, and /sys/kernel/security/tpm0/binary_bios_measurements
does not exist.
The loader can use the apposite UEFI protocol to check, which is a more
definitive answer. Given userspace can also make use of this information, export
the bitmask with the list of active banks as-is. If it's not 0, then we can be
sure a working TPM2 was available in EFI mode.
Partially fixes https://github.com/systemd/systemd/issues/38071
Currently, vmspawn is in this really weird state where vmspawn itself
and qemu will inherit the caller's execution environment but the
auxiliary
daemons it spawn will run in a fully pristine environment in the service
manager. In practice, this causes issues as checks for whether auxiliary
daemons are installed happen in the caller's execution environment but
they
might not exist in the spawned service's execution environment.
A good example of where this causes issues is trying to use
systemd-vmspawn
in our CI. We use mkosi in CI to run systemd-vmspawn in a custom
userspace
with all the necessary tools available, but systemd-vmspawn then tries
to
spawn services that run these tools using the host userspace, where the
tools are not available or too old and hence systemd-vmspawn fails to
start.
Let's make things more consistent and allow using systemd-vmspawn in CI
at
the same time by having systemd-vmspawn spawn auxiliary daemons itself
instead of having the service manager spawn them. We use
systemd-socket-activate to still have socket activation for these
services,
even though we now spawn them ourselves. To make sure we wait for
systemd-socket-activate to bind to its socket before continuing, we use
the
new general fork_notify() helper.
Why not support both "online" and "offline" operation? systemd-vmspawn
is not
well tested as is and supporting two completely separate modes for
spawning
auxiliary daemons will drastically increase the surface area for bugs.
Given
there doesn't seem to be a major benefit to running daemons in services,
it
seems better to only support offline operation and not both. Should we
want
separate resource control for the auxiliary daemons in the future, we
can run
move them into separate scopes if needed.
Aside from the usual boilerplate of moving the shared logic to shared/,
we also rework the implementation of --bind-user= to be similar to what
we'll do in systemd-vmspawn. Instead of messing with the nspawn container
user namespace, we use idmapped mounts to map the user's home directory on
the host to the mapped uid in the container.
Ideally we'd also use the "userdb.transient" credentials to provision the
user records, but this would only work for booted containers, whereas the
current logic works for non-booted containers as well.
Aside from being similar to how we'll implement --bind-user= in vmspawn,
using idmapped mounts also allows supporting --bind-user= without having to
use --private-users=.
Currently, vmspawn is in this really weird state where vmspawn itself
and qemu will inherit the caller's execution environment but the auxiliary
daemons it spawn will run in a fully pristine environment in the service
manager. In practice, this causes issues as checks for whether auxiliary
daemons are installed happen in the caller's execution environment but they
might not exist in the spawned service's execution environment.
A good example of where this causes issues is trying to use systemd-vmspawn
in our CI. We use mkosi in CI to run systemd-vmspawn in a custom userspace
with all the necessary tools available, but systemd-vmspawn then tries to
spawn services that run these tools using the host userspace, where the
tools are not available or too old and hence systemd-vmspawn fails to start.
Let's make things more consistent and allow using systemd-vmspawn in CI at
the same time by having systemd-vmspawn spawn auxiliary daemons itself
instead of having the service manager spawn them. We use
systemd-socket-activate to still have socket activation for these services,
even though we now spawn them ourselves. To make sure we wait for
systemd-socket-activate to bind to its socket before continuing, we use the
new general fork_notify() helper.
Why not support both "online" and "offline" operation? systemd-vmspawn is not
well tested as is and supporting two completely separate modes for spawning
auxiliary daemons will drastically increase the surface area for bugs. Given
there doesn't seem to be a major benefit to running daemons in services, it
seems better to only support offline operation and not both. Should we want
separate resource control for the auxiliary daemons in the future, we can run
move them into separate scopes if needed.
As a bonus, this approach allows us to get rid of the extra complexity of
having to fork off the qemu process first so we can allocate a scope for it
that the other services bind to. This means large parts of
0fc45c8d20 are reverted by this commit.
This PR rearranges fields in io.systemd.Unit.List according to
@poettering guidance:
> if a property can be set in a unit file, ever, then it belongs in
context. Otherwise, it belongs to runtime.
https://github.com/systemd/systemd/issues/38124
Systemd-stub supports loading addons, credentials, system and
configuration
extensions from ESP and while addons and credentials can be both global
and
per-UKI, sysext/confext are only per-UKI.
Add support for global sysext/confext to systemd-stub/systemd-sysext.
Fixes#37993
This adds missing glue to reasonably allow unpriv users VMs/containers
to register with the system machined.
This primarily adds two things:
1. machined can now properly track VMs/containers residing in subcgroups
of units, because that's effectively what happens for per-user
VMs/containers: they are placed below the system unit `user@….service`
in some user unit.
2. machines registered with machined now have an owning UID: users can
operate on their own machines withour re-authentication, but not on
others.
Note that this is only a first step regarding machined's hookup of
nspawn/vmspawn in the long run for unpriv operation.
I think eventually we should make it so that there's both a per-user and
a per-system machined instance (so far, and even with this PR there's
still one per-system instance), and per-user containers/VMs would
registering with *both*. Having two instances makes sense I think,
because it would mean we can make machined reasonably manage the
per-user image discovery, and also do the per-system network/hostname
handling.
So far, machined strictly tracked the "leader" process of a machine,
i.e. the topmost process that is actually the payload of the machine.
Its runtime also defines the runtime of the machine, and we can directly
interact with it if we need to, for example for containers to join the
namespaces, or kill it.
Let's optionally also track the "supervisor" process of a machine, i.e.
the host process that manages the payload if there is one. This is
generally useful info, but in particular is useful because we might need
to communicate with it to shutdown a machine without cooperation of the
payload. Traditionally we did this by simply stopping the unit of the
machine, but this is not doable now that the host machined can be used
to track per-user machines.
In the long run we probably want a more bespoke protocol between
machined and supervisors (so that we can execute other commands too,
such as request cooperative reboots/shutdowns), but that's for later.
Some environments call the concept "monitor" rather than "supervisor" or
use some other term. I stuck to "supervisor" because nspawn uses this,
and ultimately one name is as good as another.
And of course, in other implementations of VM managers of containers
there might not be a single process tracking each VM/container. Because
of this, the concept of a supervisor is optional.
Now that unpriv clients can register machines, let's register their UID
too. This allows us to do two things:
1. make sure the scope delegation is assigned to the right UID (so that
the unpriv user can actually create cgroups below the delegated
scope)
2. permit certain types of access (i.e. killing, or pty access) to the
client without auth if it owns the machine.
Load global sysext/confext from /.extra/global_{sysext,confext} which
systemd-stub puts there from ESP/loader/credentials/*.{sysext,confext}.raw.
Global extensions are handled the exact same way as per-UKI ones.
The header provides _MIPS_SIM_ABI32 and friends. Glibc indirectly includes
the header through sys/syscall.h or unistd.h, but let's explicitly include
the header where we use _MIPS_SIM_ABI32 and friends.
The header linux/quota.h provides e.g. QIF_DQBLKSIZE or PRJQUOTA, which
is used where the quota-util.h is included.
Let's explicitly include the header with 'IWYU pragma: export' tag.
Continuation of #37960.
The same concern as expalined in #37960 exists also in
missing_syscall.h. If we use enough new glibc, a function we want to use
may be already provided by glibc, but our baseline glibc may not. And it
is hard to detect in our daily development.
This moves all prototypes of syscalls to relevant headers, and missing
syscall functions are defined in relevant .c files of libc wrapper. This
way, we can use usual header as is, e.g. when we want to write code with
`move_mount()`, we can simply use sys/mount.h without checking if it is
supported by our baseline glibc.
Then, move syscall definitions to the wrapper, and prototypes are moved
to relevant headers.
This also adds checks for add_key() and request_key(), as one day
glibc may be going to add some of them separatedly.
The check for fspick in meson.build is dropped, as it is currently
unused in our code.
This also moves
- basic/missing_bpf.h -> include/override/linux/bpf.h,
- basic/missing_keyctl.h -> include/override/linux/keyctl.h.
- pass our system include directories to make generators use our libc
wrappers and latest kernel headers,
- include relevant headers in generated gperf file,
- use files() rather than find_program(), as the result of
find_program() cannot be passed to 'input' of custom_target(),
- move generate-bpf-delegate-configs.py to src/core/, as it is only used
by libcore.
Previously, the logger is only used in error paths, but since
fe3f2ac073, the logger is also used in a
success path. Let's not log loudly on success.
This also drops unused log_selinux_enforcing().
Then, make the function show the original and resolved path if they are
different.
With this change, procfs needs to be mounted on /proc/, hence the test
code is slightly updated.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Vishal Chillara SrinivasandVishwanath Chandapur
Lennart Poettering
Luca Boccassi
Luca Boccassi
Daan De Meyer
Mike Yuan
Ivan Kruglov
Vitaly Kuznetsov