These signatures can be provided by arbitrary Varlink backends symlinked
into /run/systemd/report/sign.
Also add a proper Varlink IDL for the upload interface, since we are
extended it now.
We need a removal rule for systems where /tmp is not on tmpfs,
so that if they crash, stale sockets will be removed during boot.
OTOH, at runtime, those lock files must never be removed.
But since the 'r!' rule uses '!', it only applies during boot. With
the rule inactive, the usual time-based cleanup for /tmp/ was also
applied to those files, causing them to be removed after 10 days.
Fixes#35182.
4a1f92c704 added '!' through confusion:
the goal was probably to exclude those directories from cleanup at
runtime. But as discussed below, that exclusion is not needed. In fact,
we want the rule to be active during runtime, so that if the directory
were removed or wasn't created earlier for whatever reason, it'd be
created during one of those later runs too. This just makes the system
more robust.
Those directories are used for sockets, and tmpfiles will not remove
live sockets. So it is fine to run the cleanup on those directories,
it doesn't have any effect in normal circumstances. The only case where
the cleanup would matter would be if the service was running, crashed
without removing the socket, and the system would remain up for more
than 10 days after that. This is not a particularly likely scenario, but
OTOH, we can imaging that somebody tried to run Xorg, it didn't work,
and they switched to Wayland. Or their DE crashes every once in a while,
leaving some state behind. Keeping the cleanup in place seems OK, it
makes the system slightly more robust in fringe scenarios.
In fact, this cleanup will work better if we reduce the delay from
10 days to something small. systemd-tmpfiles-clean.timer runs once
per day, so the cleanup will not be very fast anyway. So use '1h' as
an arbitrary small value. (I think '0' would be risky, because it's
possible for the socket to be set up through a script where it's
created first and the service is connected to it, so it is momentarily
"not live". I think people used to do this. Not sure if that happens
anymore, but let's be safe.)
Co-authored-by: Jarl Gullberg <jarl.gullberg@visar-systems.com>
We expose this via --private-users-delegate= which takes the number of
ranges to delegate. On top of delegating the ranges, we also mount in
the nsresourced socket and the mountfsd socket so that nested containers
can use nsresourced to allocate from the delegated ranges and mountfsd to
mount images.
Finally, we also create /run/systemd/dissect-root with systemd-tmpfiles to
make sure it is always available as unpriv users won't be able to create it
themselves.
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.
As announced by a few releases now, finally drop support for
sysvinit scripts.
Keep rc-local generator for now, as it's really a distinct
feature even though from the same era.
Instead, please use the kernel command line options with the same name.
I am not sure these files are System V complieant or not, but at least
they are very traditional way to control fsck or quotacheck.
However, the concept of the files are really broken, especially for
fsck. As when we want to fsck the root filesystem, we need to access the
filessystem, but it may be broken...
Let's drop such traditional ways to control fsck and quotacheck.
We already support kernel command line options to control the behaviors.
Maybe, also it is better to provide ways to control them by credentials.
[1] says:
> Since 0.60.0 the name argument is optional and defaults to the basename of
> the first output
We specify >= 0.62 as the supported version, so drop the duplicate name in all cases
where it is the same as outputs[0], i.e. almost all cases.
[1] https://mesonbuild.com/Reference-manual_functions.html#custom_target
That file contains a bunch of entries of which only some are related to SysV.
The rest are just "traditional APIs" that need to stay. In particular,
/var/lock a.k.a. /run/lock is used by many programs (LVM, iscsi, alsactl).
Similarly, the README about /var/log is something that should stay as long as
we have people migrating from older systems or using the copiuos documentation
that mentions /var/log/messages.txt on the Internet.
/var/lock/subsys is only used by sysvinit, and our code to support /forcefsck,
/fastboot, and /forcequotacheck is conditionalized on HAVE_SYSV_COMPAT, so
conditionalize those here on HAVE_SYSV_COMPAT too.
(This excludes any dirs that contain resources placed there by the user)
(I also didn't bother marking resources belonging to components that are
really not optional for us)
Let's move copying out the PCR signature/key into its own tmpfiles
snippet.
And then let's add support for copying out the profile + os-release
information systemd-stub now places in the invoked initrd.
That way these four pieces of information are available even after the
initrd→host transition.
On distros like SUSE where ssh config dropins in /usr are supported, there's no
need for a symlink in /etc/ssh/ssh_config.d/ that points to the dropin
installed somewhere in /usr (that is not reachable by ssh).
To make it easy to have a workable ssh-generator on various distros,
let's optionally generate the ssh privsep dir via tmpfiles.d/ drop-in.
This enables the concept with a path of /run/sshd/ as default. This is
the path Debian/Ubuntu uses, and means that we just work on those
distros. Debian/Ubuntu is the only distro (apparently?) that puts the
privsep dir under /run/, hence always needs the dir to be created
manually. Other distros don't need it that much, because they place the
dir in /usr/ (fedora, best choice!) or /var/ (others, not ideal, because
still mutable).
Also adds a longer explanation about this in NEWS, in the hope that
distro maintaines read that and maybe start cleaning this up.
Alternative to: #31543
Then, this introduces systemd-networkd-persistent-storage.service.
systemd-networkd.service is an early starting service. So, at the time
it is started, the persistent storage for the service may not be ready,
and we cannot use StateDirectory=systemd/network in
systemd-networkd.service.
The newly added systemd-networkd-persistent-storage.service creates the
state directory for networkd, and notify systemd-networkd that the
directory is usable.
20-systemd-ssh-generator.conf expands SSHCONFDIR, which is bogus when we
build with -Dsshconfdir=no. Similarly, avoid expanding SSHDCONFDIR in
20-systemd-userdb.conf when building with -Dsshconfdir=no.
Follow-up 6c7fc5d5f2.
This adds a tiny binary that is hooked into SSH client config via
ProxyCommand and which simply connects to an AF_UNIX or AF_VSOCK socket
of choice.
The syntax is as simple as this:
ssh unix/some/path # (this connects to AF_UNIX socket /some/path)
or:
ssh vsock/4711
I used "/" as separator of the protocol ID and the value since ":" is
already taken by SSH itself when doing sftp. And "@" is already taken
for separating the user name.
sshd now supports config file drop-ins, hence let's install one to hook
up "userdb ssh-authorized-keys", so that things just work.
We put the drop-in relatively early, so that other drop-ins generally
will override this.
Ideally sshd would support such drop-ins in /usr/ rather than /etc/, but
let's take what we can get. It's not that sshd's upstream was
particularly open to weird ideas from Linux people.
We have two mechanisms that remove old coredumps: systemd-coredump has
parameters based on disk use / remaining disk free, and systemd-tmpfiles does
cleanup based on time. The first mechanism should prevent us from using too much
disk space in case something is crashing continuously or there are very large
core files.
The limit of 3 days makes it likely that the core file will be gone by the time
the admin looks at the issue. E.g. if something crashes on Friday, the coredump
would likely be gone before people are back on Monday to look at it.
This reverts commit 33b91308c2.
The commit b42482af90 dropped
'--exclude-prefix=/dev' from systemd-tmpfiles-setup.service. So, the
possibly later invocation of the service changes the permission set by
udevd.
As commmented in the head of this file, settings should be consistent
with udev rules. Only missing entry here is vfio. Let's re-add the
entry for the device.
Addresses https://github.com/systemd/systemd/pull/28681#issuecomment-1666949888.
This setting allows services to run in an ephemeral copy of the root
directory or root image. To make sure the ephemeral copies are always
cleaned up, we add a tmpfiles snippet to unconditionally clean up
/var/lib/systemd/ephemeral. To prevent in use ephemeral copies from
being cleaned up by tmpfiles, we use the newly added COPY_LOCK_BSD
and BTRFS_SNAPSHOT_LOCK_BSD flags to take a BSD lock on the ephemeral
copies which instruct tmpfiles to not touch those ephemeral copies as
long as the BSD lock is held.
In b6033b7060 support was added to create
{/etc|/run}/credstore{|.encrypted} via tmpfiles.d with perms 0000. These
perms are so restrictive that not even root can access them unless it
has CAP_DAC_OVERRIDE capability. This is creates the dirs at boot time
In 24039e1207 support was added to create
/etc/credstore with perm 0700 from meson.build at build time.
This patch makes unifies the two parts:
1. creates both /etc/credstore *and* /etc/credstore.encrypted in both
places (the build system still won't create them in /run/, since
that's pointless since not shipped, and the runtime won't create the
dirs below /usr/lib/, since that's not generically writable anyway).
2. Both at runtime and at build time we'll create the dirs with mode
0700. This is easier for packaging tools to handle since they
generally react pretty negatively on dirs they can't enumerate.
I'm not sure what "suffix" was meant by this comment, but the file has the usual suffix.
The file was added with the current name back in c4708f1323.
Maybe an earlier version of the patch did something different.
Allow defining the default keymap to be used by
vconsole-setup through a build option. A template
vconsole.conf also gets populated by tmpfiles if
it doesn't exist.
This adds a tmpfiles.d/ snippet for LoadCredential= style credentials
directories in /etc/ and /run/.
This is done primarily to ensure that the access modes for the dirs are
set up properly, in the most restrictive ways. Specifically these are
set to 0000, so that CAP_DAC_OVERRIDE is necessary to enumerate and read
the credentials, and being UID=0 is not sufficient to do so.
This creates /etc/credstore/, but leaves /run/credstore/ absent if
missing, for now. Thinking is: the latter being non-persistent is
created by software usually, not manually by users, and hence more
likely right. But dunno, we might want to revisit this sooner or later.
This is ultimately an exercise to advertise the LoadCredential= concept
a bit, and do so in a reasonably secure way, underlining the safety of
the concept.
On a read-only filesystem creating /root/.ssh might fail, but that's ok.
Do not fail the run, as this is only needed to add the credential, which
is a separate step.
(s) is just ugly with a vibe of DOS. In most cases just using the normal plural
form is more natural and gramatically correct.
There are some log_debug() statements left, and texts in foreign licenses or
headers. Those are not touched on purpose.
With this, I can now easily do:
systemd-nspawn --load-credential=ssh.authorized_keys.root:/home/lennart/.ssh/authorized_keys --image=… --boot
To boot into an image with my SSH key copied in. Yay!
Now that sd-stub will place the PCR signature and its public key in
the initrd's /.extra/ directory, let's copy it from there into /run/
from userspace. This is done because /.extra/ is on the initrd's tmpfs
which will be emptied during the initrd → host transition. Since we want
these two files to survive we'll copy them – if they exist – into /run/
where they will survive the transition.
Thus, with this last change the files will have safely propagated from
their PE sections into files in /run/ where userspace can find them
The paths in /run/ happen to be the exact ones that
systemd-cryptenroll/systemd-cryptsetup/systemd-creds look for them.
