PCR 7 covers the SecureBoot policy, in particular "dbx", i.e. the
denylist of bad actors. That list is pretty much as frequently updated
as firmware these days (as fwupd took over automatic updating). This
means literal PCR 7 policies are problematic: they likely break soon,
and are as brittle as any other literal PCR policies.
hence, pick safer defaults, i.e. exclude PCR 7 from the default mask.
This means the mask is now empty.
Generally, people should really switch to signed PCR policies covering
PCR 11, in combination with systemd-pcrlock for the other PCRs.
In v257 userdbctl gained support for filtering user records with fuzzy
matching and some other parameters. It was done on the client side only.
This PR adds server-side matching, by exendting the generic userdb
varlink api.
The api is generic any may have many other implementors, hence care is
taken to fallback to exclusively client side filtering in case the
service does not support the new parameters.
In fact I even opted to not actually implement server-side filtering in
any services but systemd-userdbd.service, because it's probably not too
much an optimization in relevant services (we might want to revisit this
later). By implementing it in userdbd the primary entrypoint for userdb
is however covered: the multiplexer interface which provides a single
interface for the multitude of backends. Or in other words: the
multiplexer itself supports server-side filtering even if its own
backends don't, and will hide this neatly away.
One nice side effect from not implementing server side filtering for all
our backends is that the fallback codepaths are comprehensively tested.
Note that this adds some unit tests but not new integration test for all
this, as the filtering tests for userdbctl already existed before, we
just move their implementation from the client to the server side.
There's finally quota on tmpfs, hence let's use it to make it harder for
users to DoS the system by consuming all disk space in /tmp/ and
/dev/shm/.
This enforces a default limit of 80% quota of the backing fs for these
two dirs for users, but this can be overriden in the user record, if
desired.
This also adds two other interesting features:
1. mount units gain GracefulOptions= which takes optional mount options
that are added only if supported by the kernel. (this is used to enable
usrquota on /tmp/, if available.)
2. The PAM logic in service management now supports reading passwords
from service credentials and via the askpw logic. This used for make
testing easy (so that we can run0 into a homed user which strictly
requires a password).
This new session class is to "user" what "background" is to
"background-light": it doesn't cause the per-user service manager to
start.
This new session class is now the default if no session class was
provided at session registration time and the following conditions hold:
1. The session is not graphical
2. The user is not a regular user (but not root)
Or in other words root and system users won't get a service manager
started automatically if they go through a PAM session as part of things
like cron or ftp. They will however still get one if they log in
graphically.
This changes behaviour a bit, but hopefully in OK was.
This also makes "background-light" for system users incl. root.
This addresses one of the ideas discussed in #34988.
