`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.
Quoting "Trusted Platform Module Library - Part 3: Commands (Rev. 01.59)":
"pcrUpdateCounter – this parameter is updated by TPM2_PolicyPCR(). This value
may only be set once during a policy. Each time TPM2_PolicyPCR() executes, it
checks to see if policySession->pcrUpdateCounter has its default state,
indicating that this is the first TPM2_PolicyPCR(). If it has its default value,
then policySession->pcrUpdateCounter is set to the current value of
pcrUpdateCounter. If policySession->pcrUpdateCounter does not have its default
value and its value is not the same as pcrUpdateCounter, the TPM shall return
TPM_RC_PCR_CHANGED.
If this parameter and pcrUpdateCounter are not the same, it indicates that PCR
have changed since checked by the previous TPM2_PolicyPCR(). Since they have
changed, the previous PCR validation is no longer valid."
The TPM will return TPM_RC_PCR_CHANGED if any PCR value changes (no matter
which) between validating the PCRs binded to the enrollment and unsealing the
HMAC key, so this patch adds a retry mechanism in this case.
Fixes#24906
Inspired by #25664: let's check explicitly for NULL everywhere we do one
of those getXYZcon() calls.
We usually turn this into EOPNOTSUPP, as when selinux is off (which is
supposed to be the only case this can happen according to selinux docs)
we otherwise return EOPNOTSUPP in that case.
Note that in most cases we have an explicit mac_selinux_use() call
beforehand, hence this should mostly not be triggerable codepaths.
In order to support pivot_root() we need to move mount propagation
changes after the pivot_root(). While MS_MOVE requires the source mount
to not be a shared mount pivot_root() also requires the target mount to
not be a shared mount. This guarantees that pivot_root() doesn't leak
any mounts.
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
- add missing assertions,
- rename function arguments for storing result,
- rename variables which conflict our macros,
- always initialize function arguments for results on success.
Btrfs quotas are actually being enabled in systemd-importd via
setup_machine_directory(), not in systemd-{import,pull} where those
environment variables are checked. Therefore, also check them in
systemd-importd and avoid enabling quotas if requested by the user.
Fixes: #18421Fixes: #15903Fixes: #24387
Non-negative return values of setup_machine_directory() were never used
and never had clear meaning, so do not distinguish between various
non-error conditions and just return 0 in all cases.
Trying to disable a unit with no install info is mostly useless, so
adding a warning like we do for enable (with the new dbus method
'DisableUnitFilesWithFlagsAndInstallInfo()'). Note that it would
still find and remove symlinks to the unit in /etc, regardless of
whether it has install info or not, just like before. And if there are
actually files to remove, we suppress the warning.
Fixes#17689
This function checks if the external verity data referenced in
VeritySettings covers the specified partition (indicated via
designator).
Right now, we'll use that at one place, but in a later commit in more.
Let's store the GPT partition flags in the dissected partition info.
Right now we won't actually use them for anything yet, but later we'll
add that, when enforcing policy on dissection.
let's make sure we can probe file systems also when unprivileged:
instead of probing the partition block devices for file system
signatures, let's go via the original "whole" fd.
libblkid makes this easy actually, as it allows us to specify the
offset/size of the area to probe. And we have the partition
offsets/sizes anyway, so it's trivial for us to make use of.
This thus enables fs probing also when lacking privs and operating on
naked regular files without loopback devices or anything like this.
When repeatedly appending an object to a growing array, we would create a new
array larger by one slot, insert all the old entries and the new element with
ref count bumps into the new array, and then unref the old array.
This would cause problems when building an array with more than a few thousand
elements. If userdbctl is modified to construct an array,
'userdbctl --json=pretty group >/dev/null' with 31k groups:
0.74s (existing code)
102.17s (returning an array)
0.79s (with this patch)
We append arrays in various places, so it seems nice to make this generally
fast.
The source would be set implicitly when parsing from a named file. But
it's useful to specify the source also for cases where we're parsing a
ready string. I noticed the lack of this API when trying to write tests,
but it seems generally useful to be specify a source name when parsing
things.
We would output a sequence of concatenated JSON strings. 'jq' accepts such
output without fuss, and can even automatically build an array with --slurp/-s.
Nevertheless, parsing this format is more effort for the reader, since it's not
"standard JSON". E.g. Python's json module cannot do this out-of-the-box, but
needs some loop with json.JSONDecoder.raw_decode() and then collecting the
objects into an array. Such streaming output make sense in case of logs, where
we stream the output and it has no predefined length. But here we expect at
most a few dozen entries, so it's nicer to write normal JSON that is trivial to
parse.
I'm treating this is a bugfix and not attempting to provide compatibility
backwards. I don't think the previous format was seeing much use, and it's
trivial to adapt to the new one.
libblkid really should define an enum for this on its own, but it
currently doesn't and returns literal numeric values. Lets make this
more readable by adding our own symbolic names via an enum.
Curently, these two flags were implied by dissect_loop_device(), but
that's not right, because this means systemd-gpt-auto-generator will
dissect the root block device with these flags set and that's not
desirable: the generator should not cause the partition devices to be
created (we don't intend to use them right-away after all, but expect
udev to find/probe them first, and then mount them though .mount units).
And there's no point in opening the partition devices, since we do not
intend to mount them via fds either.
Hence, rework this: instead of implying the flags, specify them
explicitly.
While we are at it, let's also rename the flags to make them more
descriptive:
DISSECT_IMAGE_MANAGE_PARTITION_DEVICES becomes
DISSECT_IMAGE_ADD_PARTITION_DEVICES, since that's really all this does:
add the partition devices via BLKPG.
DISSECT_IMAGE_OPEN_PARTITION_DEVICES becomes
DISSECT_IMAGE_PIN_PARTITION_DEVICES, since we not only open the devices,
but keep the devices open continously (i.e. we "pin" them).
Also, drop the DISSECT_IMAGE_BLOCK_DEVICE combination flag, since it is
misleading, i.e. it suggests it was appropriate to specify on all
dissected blocking devices, but that's precisely not the case, see the
systemd-gpt-auto-generator case. My guess is that the confusion around
this was actually the cause for this bug we are addressing here.
Fixes: #25528
When copying between filesystems, sometimes the target filesystem
might not support symlinks/fifos/sockets/... and we want to log and
ignore any failures to copy such files when copying. Let's introduce
a new flag to enable this behavior.
Luca Boccassi
Yu Watanabe
Peter Cai
Lennart Poettering
jcg
Antonio Alvarez Feijoo
Aidan Dang
Christian Brauner
Zbigniew Jędrzejewski-Szmek
Ivan Shapovalov
Mike Yuan
Daan De Meyer