pid1: downgrade if we can't make sense of the old device on MOVE uevent
If the name of the old device didn#t work for us, we don't have to clean
anything up, since we know for sure that there won't be a device unit
for it. hence downgrade log message about it.
pid1: properly propagate errors from device_setup_unit()
We want to propagate errors here, since we want to make dependent on the
success of creating the main device unit the creation of the auxiliary
device units. Thus if we suppress errors here we might end up in exotic
corner cases in a situation were we create the auxiliary ("following")
device units without the primary one.
ask-password: make password echo fully configurable
This adds --visible=yes|no|asterisk which allow controlling the echo of
the password prompt in detail. The existing --echo switch is then made
an alias for --visible=yes (and a shortcut -e added for it too).
Yu Watanabe [Wed, 2 Jun 2021 07:29:59 +0000 (16:29 +0900)]
sd-device: do not use ::subsystem member directly
The value is set dynamically when sd_device_get_subsystem() is called
first time.
Fixes the following issue:
```
$ build/udevadm test /sys/class/block/dm-1
...
Assertion '_subsystem' failed at src/libsystemd/sd-device/sd-device.c:767, function device_set_subsystem(). Aborting.
Program received signal SIGABRT, Aborted.
```
various: don't say that the timestamp 'changed' on initial load
I always found this a bit annoying.
With the patch:
$ SYSTEMD_LOG_LEVEL=debug build/udevadm test /sys/class/block/dm-1
...
Loaded timestamp for '/etc/systemd/network'.
Loaded timestamp for '/usr/lib/systemd/network'.
Parsed configuration file /usr/lib/systemd/network/99-default.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
Loaded timestamp for '/etc/udev/rules.d'.
Loaded timestamp for '/usr/lib/udev/rules.d'.
...
dissect: if dissecting without udev, don't look for usec timestamp on db record
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.
pam: do not require a non-expired password for user@.service
Without this parameter, we would allow user@ to start if the user
has no password (i.e. the password is "locked"). But when the user does have a password,
and it is marked as expired, we would refuse to start the service.
There are other authentication mechanisms and we should not tie this service to
the password state.
The documented way to disable an *account* is to call 'chage -E0'. With a disabled
account, user@.service will still refuse to start:
systemd[16598]: PAM failed: User account has expired
systemd[16598]: PAM failed: User account has expired
systemd[16598]: user@1005.service: Failed to set up PAM session: Operation not permitted
systemd[16598]: user@1005.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
systemd[1]: user@1005.service: Main process exited, code=exited, status=224/PAM
systemd[1]: user@1005.service: Failed with result 'exit-code'.
systemd[1]: Failed to start user@1005.service.
systemd[1]: Stopping user-runtime-dir@1005.service...
cryptsetup: don't bother waiting for TPM2 devices if we are on EFI and EFI says there is no TPM2 device
Note that this means EFI-systems with a manually added TPM device won't
be supported automatically, but given that the TPM2 trust model kinda
requires firmware support I doubt it matters supporting this. And in all
other cases it speeds things up a bit.
cryptsetup: explicitl set default log functions wherever needed
Code using libcryptsetup already sets the global log function if it uses
dlopen_cryptsetup(). Make sure we do the same for the three programs
that explicitly link against libcryptsetup and hence to not use
dlopen_cryptsetup().
cryptsetup: implicitly set global log functions when loading libcryptsetup dynamically
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.
userdb: make most loading of JSON user record data "permissive"
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.
homectl: store FIDO2 up/uv/clientPin fields in user records too
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".
journal-remote: downgrade messages about input data to warnings
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".
systemctl: unset const char* arguments in static destructors
When fuzzing, the following happens:
- we parse 'data' and produce an argv array,
- one of the items in argv is assigned to arg_host,
- the argv array is subsequently freed by strv_freep(), and arg_host has a dangling symlink.
In normal use, argv is static, so arg_host can never become a dangling pointer.
In fuzz-systemctl-parse-argv, if we repeatedly parse the same array, we
have some dangling pointers while we're in the middle of parsing. If we parse
the same array a second time, at the end all the dangling pointers will have been
replaced again. But for a short time, if parsing one of the arguments uses another
argument, we would use a dangling pointer.
Such a case occurs when we have --host=… --boot-loader-entry=help. The latter calls
acquire_bus() which uses arg_host.
I'm not particularly happy with making the code more complicated just for
fuzzing, but I think it's better to resolve this, even if the issue cannot
occur in normal invocations, than to deal with fuzzer reports.
Should fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31714.
This line is so long, that the end is usually not visible on
the terminal. The dot looks out of place, and dropping it saves one
column for more interesting content.
tty-ask-password-agent: log when starting a query on the console
When looking at logs from a boot with an encrypted device, I see
(with unrelevant messages snipped):
[ 2.751692] systemd[1]: Started Dispatch Password Requests to Console.
[ 7.929199] systemd-cryptsetup[258]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/2d9b648a-15b1-4204-988b-ec085089f8ce.
[ 9.499483] systemd[1]: Finished Cryptography Setup for luks-2d9b648a-15b1-4204-988b-ec085089f8ce.
There is a hug gap in timing without any explanatory message. If I didn't type
in the password, there would be no way to figure out why things blocked from
this log, so let's log something to the log too.
projects / thirdparty / systemd.git / log
