This also relaxes the inode access modes a bit, in case they were set to
0600: we now set the "r" bit too, i.e. use 0644. This is beneficial
since it permits unpriv code to read the xattrs of the entrypoints
(which require read access). Note that in order to be able to connect()
to a socket inode you need write access, hence this shouldn't compromise
security in any way.
So far we didn't provide any concept to enumerate local Varlink
services. Let's change that.
Let's define very light-weight scheme for this: provide a well-known dir
/run/varlink/registry/ where services that implement public interfaces
can link their sockets into. When enumerating services it's thus
sufficient to enumerate inodes in that directory.
The usecase for this is twofold:
1. It's simply very useful to be able to see which public services are
bound on the local system, for debugging/admin/development purposes.
2. At Amutable we'd like to optionally provide a HTTP-to-Varlink bridge
on individual nodes, that allows remote peers (after authentication)
to access local Varlink services. For that it's essential we know the
list of services and their entrypoints to expose, it would be
security-wise highly problematic for clients to provide AF_UNIX
entrypoint paths when connecting. hence: let's instead just have a
dir with the public stuff, and let's ensure the HTTP-to-Varlink
bridge simply exposes that stuff, and nothing else.
Non-public interfaces (such as the oomd interfaces between PID 1 and
oomd), and interfaces with multiple implementors (such as the resolved
hook interface, or the metrics collection stuff) should not be linked
in.
This is inspired by the Varlink.org "registry" concept, briefly
explained here:
https://varlink.org/FAQ#how-do-i-find-the-service-which-implements-a-local-interface
Note however that the described Varlink interface is not actually
implemented here, the directory is introduced however in a fashion that
conceptually matches the registry defined there, and would allow us to
implement the registry interface on top of it. (One of the reason the
registry Varlink API is not implemented right now is that the URI format
it relies on is entirely unspecified in the Varlink docs right now. Some
research needs to be done to extract what's implemented in the reference
implementation and to determine how it maps to the Varlink entrypoint
address format systemd's own tooling currently uses)
This primarily installs the symlinks via Symlinks= in unit files and via
a new tmpfiles.d/ drop-in. But since we touch all .socket units relating
to Varlink this also sets the FileDescriptorName= to varlink for each,
just to minimize diffrences and make things work more alike (the
services in questin don't care about the name, so this doesn't change).
In one case we replace a pair of separate sockets for two closely
related varlink services by a socket and a symlink, so that we can
safely use Symlinks= to also install the registry symlinks.
We generally don't specify the protocol implementation in unit descriptions.
For journald, we have:
$ git grep Description 'units/*journald*'
units/systemd-journald-audit.socket:Description=Journal Audit Socket
units/systemd-journald-dev-log.socket:Description=Journal Socket (/dev/log)
units/systemd-journald-varlink@.socket:Description=Journal Varlink Socket for Namespace %i
units/systemd-journald.service.in:Description=Journal Service
units/systemd-journald.socket:Description=Journal Sockets
units/systemd-journald@.service.in:Description=Journal Service for Namespace %i
units/systemd-journald@.socket:Description=Journal Sockets for Namespace %i
so we need to keep "Varlink" in the name. But also use "Sockets" (plural)
for the "main" socket unit, since it opens multiple sockets.
I was looking at the logs in some bug and saw this:
Mar 13 15:55:12 fedora systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Mar 13 15:55:12 fedora systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
Mar 13 15:55:12 fedora systemd[1]: systemd-tpm2-setup-early.service - TPM2 SRK Setup (Early) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
This is overly technical, for most units we don't provide this level of
detail about the implementation. So retitle the units to be more accessible.
Also, the fact that it's a v. 2 of the TPM is not that important. We don't
support TPM 1.2, but computers without TPM v2 are getting rare. For other
units we don't advertise the version of hardware, and let's not do this here,
to reduce some complexity.
Lennart Poettering
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Lennart Poettering