We had:
systemd[1]: varlink-36: New incoming message: {"method":"io.systemd.UserDatabase.GetMemberships","parameters":{"userName":"gdm","service":"io.systemd.DynamicUser"},"more":true}
systemd[1]: varlink-36: varlink: changing state idle-server → processing-method-more
systemd[1]: varlink-36: Sending message: {"error":"io.systemd.UserDatabase.NoRecordFound","parameters":{}}
systemd[1]: varlink-36: varlink: changing state processing-method-more → processed-method
systemd[1]: varlink-36: varlink: changing state processed-method → idle-server
systemd[1]: varlink-36: Got POLLHUP from socket.
systemd[1]: varlink-36: varlink: changing state idle-server → pending-disconnect
systemd[1]: varlink-36: varlink: changing state pending-disconnect → processing-disconnect
systemd[1]: varlink-36: varlink: changing state processing-disconnect → disconnected
So let's drop the "varlink:" prefix and use capitalized sentences like in other messages.
For new connections, we log something like this:
systemd[1]: n/a: New incoming connection.
systemd[1]: n/a: Connections of user 997: 0 (of 1024 max)
systemd[1]: varlink-22: varlink: setting state idle-server
systemd[1]: varlink-22: New incoming message: ...
This "n/a" is not very pretty, and without context it would be hard to even
figure out this is a varlink connection.
There will likely be none, hence don't bother.
This fixes an issue in systemd-gpt-auto-generator where we'll try to
wait for the udev db for the partitions even though though udev might
simplynot be around and via the DISSECT_IMAGE_NO_UDEV flag were
explicitly told not to bother.
Fixes: #19377
No need to benchmark pbkdf when asking for minimal values
anyway.
1000 iterations count is minimum for both LUKS1 and LUKS2
pbkdf2 keyslot parameters according to NIST SP 800-132, ch. 5.2.
Iterations count can not be lower than recommended minimum
when benchmark is disabled. The time_ms member is ignored with
benchmark disabled.
So far we only set the per-crypt_device log functions, but some
libcryptsetup calls we invoke without a crypt_device objects, and we
want those to redirect to our infra too.
We want user records to be extensible, hence we shouldn't complain about
fields we can't parse. In particular we want them to be extensible for
our own future extensions.
Some code already turned the permissive flag when parsing the JSON data,
but most did not. Fix that. A few select cases remain where the bit is
not set: where we just gnerated the JSON data ourselves, and thus can be
reasonably sure that if we can't parse it it's our immediate programming
error and not just us processing a user record from some other tool or a
newer version of ourselves.
This catches up homed's FIDO2 support with cryptsetup's: we'll now store
the uv/up/clientPin configuration at enrollment in the user record JSON
data, and use it when authenticating with it.
This also adds explicit "uv" support: we'll only allow it to happen when
the client explicity said it's OK. This is then used by clients to print
a nice message suggesting "uv" has to take place before retrying
allowing it this time. This is modelled after the existing handling for
"up".
Giving --echo to systemd-ask-password allows to echo the user input.
There's nothing secret, so do not show a lock and key emoji by default.
The behavior can be controlled with --emoji=yes|no|auto. The default is
auto, which defaults to yes, unless --echo is given.
Those are unexpected, so a user-visible message seems appropriate.
But they are not our errors, and to some extent we can recover from
them, so "warning" seems more appropriate than "error".
Let's show the touch emoji whenever the user is likely going to have to
interact with the security token. We had this at many but not all such
messages. Let's add it everywhere.
Also, upgrade all messages where the user is supposed to do something to
LOG_NOTICE. Previously some where at LOG_NOTICE and others at LOG_INFO.
These messages are more than informational after all, they require user
action, hence deserve the higher prio, in particular as that formats
them bold with our usual log coloring.
Always use the word "test" in log messages, instead of "check".
Finally, always use the same wording: "confirm presence on security
token" for "up" and "verify user on security token" for "uv"
Let's improve compatibility with systemd 248 enrollments of FIDO2 keys:
if we have no information about the up/uv/pin settings, let's try to
determine them automatically, i.e. use up and pin if needed.
This only has an effect on LUKS2 volumes where a FIDO2 key was enrolled
with systemd 248 and thus the JSON data lacks the up/uv/pin fields. It
also matters if the user configured FIDO2 parameters explicitly via
crypttab options, so that the JSON data is not used.
For newer enrollments we'll stick to the explicit settings, as that's
generally much safer and robust.
We need really need to trust the feature set, since we are about to set
it in stone storing the result in JSON, hence react a bit more allergic
about token that misadvertise the feature.
Note that I added this to be defensive, I am not aware any token that
actually misadvertises this. hence it should be safe to make this fatal,
and should this not work we can always revisit things.
Let's try to handle keys gracefully that do not implement all features
we ask for: simply turn the feature off, and continue.
This is in particular relevant since we enroll with PIN and UP by
default, and on devices that don't support that we should just work.
Replaces: #18509
This moves the definition of the specifier table consisting only of
system and /tmp specifiers into generic code so that we can share it.
This patch only adds one user of it for now. Follow-up patches will add
more.
Previously, we supported only "," as separator. This adds support for
"+" and makes it the documented choice.
This is to make specifying PCRs in crypttab easier, since commas are
already used there for separating volume options, and needless escaping
sucks.
"," continues to be supported, but in order to keep things minimal not
documented.
Fixe: #19205
Instead of comparing strings everywhere, let's use the new enum. This
allows us to drop sleep_settings(), since the operation enum can be
directly used as index into the config settings.
Some minor other refactoring is done, but mostly just shifting thing
around a bit, no actual change in behaviour.
The kernel still provides the /proc and cgroup pressure files even
if its psi support is disabled, so we need to actually read the files
to verify they don't return -EOPNOTSUPP
We recently started making more use of malloc_usable_size() and rely on
it (see the string_erase() story). Given that we don't really support
sytems where malloc_usable_size() cannot be trusted beyond statistics
anyway, let's go fully in and rework GREEDY_REALLOC() on top of it:
instead of passing around and maintaining the currenly allocated size
everywhere, let's just derive it automatically from
malloc_usable_size().
I am mostly after this for the simplicity this brings. It also brings
minor efficiency improvements I guess, but things become so much nicer
to look at if we can avoid these allocation size variables everywhere.
Note that the malloc_usable_size() man page says relying on it wasn't
"good programming practice", but I think it does this for reasons that
don't apply here: the greedy realloc logic specifically doesn't rely on
the returned extra size, beyond the fact that it is equal or larger than
what was requested.
(This commit was supposed to be a quick patch btw, but apparently we use
the greedy realloc stuff quite a bit across the codebase, so this ends
up touching *a*lot* of code.)
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Ondrej Kozina
Christian Hesse
Luca Boccassi
Dan Streetman