After #25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.
Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.
Fixes#19208.
This tool was "deprecated" back in 65eb4378c3,
but only by removing documentation. This is somewhat surprising, but udevadm
hwdb --update and systemd-hwdb update generate different databases. udevadm
runs in compat mode and (as far as I have been able to figure out from a quick
look), it omits filename information and does some other changes to the
datastructures. The consuming code (udev) is the same in both cases, so this
"compatibility mode" seems very strange. But I don't think it's worth trying to
figure out why things were done this way. Let's just push people towards the
new code.
Inspired by https://github.com/systemd/systemd/issues/25698#issuecomment-1346298094.
If an attribute is read but the value is not used (i.e. ret_value is NULL),
then sd_device_get_sysattr_value() mistakenly frees the read data even though
it is cached internally.
Fixes a bug introduced by acfc2a1d15.
Fixes#25702.
`fido2_is_cred_in_specific_token()` should simply not return error codes
for non-fatal errors. For example, `-ENODEV` can be safely translated to
a `false` return value. When the pre-flight request is not supported, we
should simply return true to instruct the caller to attempt to use the
device anyway.
All error codes returned by the funtion should now be fatal and logged
at error level. Non-fatal errors should only appear in debug logs.
This prevents unnecessary user interactions when `fido2-device` is set to
something other than `auto` -- a case overlooked in the original PR #23577
(and later #25268).
We do not move pre-flight checks to `fido2_use_hmac_hash_specific_token`
because the behaviors are different between different cases: when the
device path is NULL, we try to automatically choose the correct device,
in which case pre-flight errors should be "soft" errors, without
spamming the tty with error outputs; but when a specific device path is
given, a pre-flight request that determined the non-existence of the
credential should be treated the same as a failed assertion request.
According to the FIDO2 spec, tokens may not support pre-flight checks
for credentials requiring UV, at least not without at least
`pinUvAuthParam` or `uv = true`. Originally, in #25268, this was
handled by passing a PIN to satisfy `pinUvAuthParams`, but this is not
ideal, since `pinUvAuthParam` can be obtained from either a PIN
or a UV verification. Forcing the user to enter the PIN here (which is
often just the fallback option on UV devices) is no better than just
trying out each device with the actual assertion request.
As a result, this commit disables pre-flight checks when the credential
requires UV, and instead reverts to the old behavior (trying out each
device and each key slot, requiring multiple user interactions) for this
type of credentials.
So, i think "erofs" is probably the better, more modern alternative to
"squashfs". Many of the benefits don't matter too much to us I guess,
but there's one thing that stands out: erofs has a UUID in the
superblock, squashfs has not. Having an UUID in the superblock matters
if the file systems are used in an overlayfs stack, as overlayfs uses
the UUIDs to robustly and persistently reference inodes on layers in
case of metadata copy-up.
Since we probably want to allow such uses in overlayfs as emplyoed by
sysext (and the future syscfg) we probably should ramp up our erofs game
early on. Hence let's natively support erofs, test it, and in fact
mention it in the docs before squashfs even.
- add missing assertions,
- use size_t for buffser size or memory index,
- handle empty input more gracefully,
- return the length or the result string,
- fix off-by-one issue when the prefix is already long enough.
Since commit 1ad6e8b302, unsetting an environment
variable means restoring it to its default value.
However this doesn't work well when localed updates locale.conf. Indeed when a
variable is removed from that file, localed calls "UnsetAndSetEnvironment"
method which restores the default values of the unset variables obtained by
PID1 when it first read locale.conf. But since locale.conf has been updated,
these default values might be outdated and localed needs to instruct PID1 to
read locale.conf again.
Reloading PID1 configuration is quite an heavy operation for this purpose but
there's no other way unless we change again the meaning of "UnsetEnvironment"
or we introduce a new method that really unset an env variable.
That said given the fact that localed modifies locale.conf, it should have an
effect on PID1 default environment rather than on the environment explicitly
set by the user (m->client_manager).
This drops the special casing for s390 and other archs, which was
cargo-culted from glibc. Given it's not obvious why it exists, and is at
best an optimization let's simply avoid it, in particular as the archs
are relatively non-mainstream.
Inspired by: #25636
Let's allow using this in code shared between userspace and EFI mode.
Also, don't implement these functions via endianness conversions given
we don't actually want to convert endianess here.
A FreezeUnit operation can hang due to the presence of kernel threads
(see last 2 commits). Keeping the default configuration will mean the
system will hang for 25 seconds in suspend waiting for the response. 1.5
seconds should be sufficient for most cases.
The `frozen` state can be `0` while the processes are indeed frozen (see
last commit). Therefore do not respect cgroup.events when checking
whether thawing is necessary.
This is useful for operating in ephemeral, writable mode on any image,
including read-only ones. It also has the benefit of not keeping the
image file's filesystem busy.
Inspired by the discussions in #25648