efi: add const qualifier to string utils

efi: include endian.h to handle endian correctly

The macro __BYTE_ORDER__ is defined in endian.h.

efi: do not use _STRING_ARCH_unaligned macro

It is already removed from glibc. See,
https://sourceware.org/git/?p=glibc.git;a=commit;h=16396c41deab45f715ffd813280d9d685b3b281e
https://sourceware.org/git/?p=glibc.git;a=commit;h=09a596cc2cf4e0f9f8e9f3bba4b1a97efcb13bcb

string-util: trivial optimizations for strverscmp_improved()

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.

Fixes: #19377

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...

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1961746.

Merge pull request #19774 from poettering/tpm2-tweaks

cryptsetup: two minor tpm2 tweaks

logind-dbus: correctly calculate when to create /etc/nologin file in all cases

Fixes: #19258

cryptsetup: add missing error branch

Found in the process of trying to figure out #19193, but I doubt it's
going to fix that.

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: if TPM2 support is not compiled in, fallback to non-TPM2 mode gracefully

Fixes: #19177

Merge pull request #19768 from poettering/homectl-fido2-lock-with

homed: catch up with FIDO2 features in cryptsetup + other fixes

cryptsetup-util: disable pbkdf benchmark in cryptsetup_set_minimal_pbkdf.

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.

dissect: the libcryptsetup code for Verity crypt_device objects too

Across the codebase we are pretty good at setting the per-crypt_device
log functions once we allocated the object. But we forgot one case. Fix
that.

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.

homework: only default to LUKS storage if libcryptsetup is installed

homework: make libcryptsetup dep runtime optional

homework: fix return codes when using fido2/pkcs11 cached passwords

Otherwise we'll accidently report a record we can safely decrypt as not
decrypted.

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".

Merge pull request #17096 from eworm-de/ask-password

ask-password: allow to control emoji

Merge pull request #19766 from keszybz/fuzz-fixes

Fuzz fixes

udevadm: output trigger UUID in UUID format, instead of ID128

The SYNTH_UUID property also shows it in UUID format, and so does the
kernel and its docs otherwise, hence accept our fate and also output it
in UUID.

Merge pull request #19765 from keszybz/early-boot-logging-improvements

Early boot logging improvements

ask-password: use FLAGS_SET()

Check for flags with FLAGS_SET() where possible.

ask-password: allow to control lock and key emoji

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.

fuzz-journal-remote: print some kinds of errors

In https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34803, we fail with:

  Assertion 'IN_SET(r, -ENOMEM, -EMFILE, -ENFILE)' failed at src/journal-remote/fuzz-journal-remote.c:69,
    function int LLVMFuzzerTestOneInput(const uint8_t *, size_t)(). Aborting.
  AddressSanitizer:DEADLYSIGNAL

Let's try to print the error, so maybe we can see what is going on.
With the previous commit we shouldn't print out anything.

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.

pid1: remove dot from initial announcement

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.

tty-ask-password-agent: highlight summary in help

tty-ask-password-agent: mention optional argument in help

0cf84693877f060254f04cf38120f52c2aa3059c added --console.
6af621248f2255f9ce50b0bafdde475305dc4e57 added an optional argument, but didn't
update the help texts.

Note that there is no ambiguity with the optional argument because no positional
arguments are allowed.

Respect option 'silent' on cryptsetup FIDO2 pin entry

Makes the silent flags behavior consistent between regular password
entry and FIDO2 pin entry.

systemctl: put static destructor in the order of variables

Merge pull request #19759 from poettering/emoji-token-text

fido2: add emoji to log message whenever "up" or "uv" is requested

cryptenroll: remove a tiny bit of whitespace

fido2: add emoji to log message whenever "up" or "uv" is requested

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"

Merge pull request #19756 from poettering/fido2-enroll-tweaks

further tweaks to fido2 code

man: document that FIDO2 uv/up/clientPin feature support is now handled gracefully

cryptsetup: revert to systemd 248 up/pin/uv FIDO2 settings when we don't have LUKS2 JSON data telling us the precise configuration

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.

fido2: properly handle case when no PINs are specified during auth

Also, drop redundant check for has_client_pin, which can never happen,
since we already filtered this case a bit further up.

fido2: make misadvertised clientPin feature fatal

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.

cryptenroll: handle FIDO2 tokens gracefully that lack requested features

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

Merge pull request #19754 from yuwata/fix-coverity-issues-and-typo

Fix coverity issues and typo

tree-wide: fix typo

basic/unit-file: fix use-after-free

This fixes a bug introduced by e8630e695232bdfcd16b55f3faafb4329c961104.

Fixes CID#1453292.

network,sd-hwdb: voidify fchmod()

Fixes CID#1453294.

path-util: add missing varargs cleanup

Fixes CID#1453293.

Merge pull request #19485 from yuwata/path-util

path-util: introduce several path utilities and handle "." more gracefully

path-util: make path_simplify() use path_find_first_component()

tree-wide: always drop unnecessary dot in path

path-util: make path_extract_filename/directory() handle "." gracefully

This makes the functions handle "xx/" and "xx/." as equivalent.
Moreover, now path_extract_directory() returns normalized path, that is
no redundant "/" or "/./" are contained.

path-util: introduce path_find_last_component()

path-util: use path_equal() in empty_or_root()

fs-util: make chase_symlinks() use path_find_first_component()

The previous commit about path_compare() breaks chase_symlinks().
This commit fixes it.

path-util: make path_compare() and path_hash_func() ignore "."

This also makes path_compare() may return arbitrary integer as it now
simply pass the result of strcmp() or memcmp().

This changes the behavior of path_extract_filename/directory() when
e.g. "/." or "/./" are input. But the change should be desired.

path-util: use path_find_first_component() in path_make_relative()

This also makes the function checks the result is a valid path or not.

path-util: use path_find_first_component() in path_startswith()

This makes path_startswith() stricter. If one of the path component in
arguments is longer than NAME_MAX, it returns NULL.

path-util: use path_is_safe() in path_is_normalized()

path-util: introduce path_is_safe()

The function is similar to path_is_valid(), but it refuses paths which
contain ".." component.

path-util: use path_find_first_component() in path_is_valid()

path-util: introduce path_find_first_component()

The function may be useful to iterate on each path component.

path-util: fix off by one issue to detect slash at the end in path_extend()

test/networkd-test: in bridge test, wait for online after restart systemd-networkd

without waiting for online, there is a race condition between systemd-networkd
actually setting the new values and the test checking those values

This also sets the link down before restarting systemd-networkd, to avoid
the wait for online being a no-op

meson: Correctly validate that prefix is a child of rootprefix

In commit d895e10a a test was introduced to validate that prefix is a
child of rootprefix. However, it only works when rootprefix is "/".
Since the test is ignored when rootprefix is equal to prefix, this is
only noticed if specifying both -Drootprefix= and -Dprefix=, e.g.:

  $ meson foo -Drootprefix=/foo -Dprefix=/foo/bar
  meson.build:111:8: ERROR: Problem encountered: Prefix is not below
  root prefix (now rootprefix=/foo prefix=/foo/bar)

Merge pull request #19749 from poettering/path-extend

add path_extend() helper which is a like if path_join() and strextend() had a baby

tree-wide: make use of path_extend() at many places

This is not a comprehensive port, but mostly some low-hanging fruit.

path-util: add path_extend(), inspired by strextend(), but using path_join()

Merge pull request #19703 from yuwata/network-ndisc-valid-time

network: ndisc: always honor valid time

Merge pull request #19743 from yuwata/dhcpv4-static-leases

network: dhcp-server:  support static lease

network: ndisc: update log message

network: ndisc: always honor valid time

See draft-ietf-6man-slaac-renum-02, section 4.2.
https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum#section-4.2

Replaces #15260.

test-network: add a testcase for DHCP static lease

network: dhcp-server: introduce [DHCPServerStaticLease] section

sd-dhcp-server: support static address to DHCPv4 offer

Merge pull request #19736 from poettering/udev-trigger-uuid

sd-device: add support for triggering devices with UUID support

man: fix tag type

This is an option, not a command.

hash-func: change value type of string_hash_ops_free_free to void*

The generic string_hash_ops_free_free hash operations vtable currently
assumes the data pointer is of type char*. There's really no reason to
assume that though, we regularly store non-string data as value in a
hashmap. Hence, to accomodate for that, use void* as pointer for the
value (and keep char* for the key, as that's what
string_hash_ops_free_free is for, after all).

udevadm: make use of the new uuid-enabled triggering for "udevadm trigger"

This adds two things:

- A new switch --uuid is added to "udevadm trigger". If specified a
  random UUID is associated with the synthettic uevent and it is printed
  to stdout. It may then be used manually to match up uevents as they
  propagate through the system.

- The UUID logic is now implicitly enabled if "udevadm trigger --settle"
  is used, in order to wait for precisely the uevents we actually
  trigger. Fallback support is kept for pre-4.13 kernels (where the
  requests for trigger uevents with uuids results in EINVAL).

sd-device: add API for triggering synthetic uevents with UUID

Since kernel 4.13 the kerne allows passing a UUID to generated uevents.
Optionally do so via a new sd_device_trigger_with_uuid() call, and add
sd_device_get_trigger_uuid() as helper to retrieve the UUID from a
uevent we receive.

This is useful for tracking uevents through the udev system, and waiting
for specific triggers.

(Note that the 4.13 patch allows passing arbitrary meta-info into the
uevent as well. This does not add an API for that, because I am not
convinced it makes sense — as it conflicts with our general rule that
events are "stateless" if you so will — and it complicates the interface
quite a bit).

This replaces #13881 in a way, which added a similar infra, but which
stalled, and whose synchronous settling APIs are somewhat problematic
and probably not material to merge.

man: document that it is guaranteed that generated ID128 are never all-zero or all-one

This is the case because the ID128 we generate are all marked as v4 UUID
which requires that some bits are zero and others are one. Let's
document this so that people can rely on SD_ID128_NULL being a special
value for "uninitialized" that is always distinguishable from generated
UUIDs.

update TODO

Merge pull request #19737 from poettering/default-specifiers-env

pid1: add specifier expansion for DefaultEnvironment=

Mount all fs nosuid when NoNewPrivileges=yes

When `NoNewPrivileges=yes`, the service shouldn't have a need for any
setuid/setgid programs, so in case there will be a new mount namespace anyway,
mount the file systems with MS_NOSUID.

man: fix list of escaped characters in unit names

The code works differently than the docs, and the code is right here.
Fix the doc hence.

See VALID_CHARS in unit-name.c for details about allowed chars in unit
names, but keep in mind that "-" and "\" are special, since generated by
the escaping logic: they are OK to show up in unit names, but need to be
escaped when converting foreign strings to unit names to make sure
things remain reversible.

Fixes: #19623

Merge pull request #19729 from poettering/networkctl-netns-check

networkctl: check that client netns matches networkd netns

core: support specifier expansion in DefaultEnvironment= and ManagerEnvironment=

Strictly speaking adding this is a compatibility break, given that
previously % weren't special. But I'd argue that was simply a bug, as
for the much more prominent Environment= service setting we always
resolved specifiers, and DEfaultEnvironment= is explicitly listed as
being the default for that. Hence, let's fix that.

Replaces: #16787

repart: resolve $TMP specifiers too

This might be useful for CopyFiles=, to reference some subdir of $TMP in
a generic way. This allows us to use the new common
system_and_tmp_specifier_table[].

sysusers: add a generic specifier table for common cases

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.

hexdecoct: make return parameters of unbase64mem() and unhexmem() optional

Inspired by: #19059

test-network: refuse RA if not necessary

test-network: wait for that the link is in configuring state at the beginning

man: document udevadm info output prefixes

Fixes: #19663

man: try to clarify that nss-mymachines does not provide name resolution outside its own scope

Fixes: #18229

man: explicit say for priority/weight values whether more is more or less

Fixes: #17523

networkctl: politely refuse being called from a different netns than the networkd instance we talk to

Otherwise things get very confusing since we mix up netens data from our
client side and from the data we retrieve from networkd.

In the long run we should teach networkctl some switch to operate safely
on other netns, and in that case also determine the right networkd
instance for that namespace.

Fixes: #19236

networkd: add bus property exposing network namepace ID we run in

This is useful for clients to determine whether they are running in the
same network namespace as networkd.

Note that access to /proc/$PID/ns/ is restricted and only permitted to
equally privileged programs. This new bus property is primarily a way to
work around this, so that unprivileged clients can determine the
networkd netns, too.

README: drop reference to Kinvolk

Kinvolk got bought by Microsoft recently, I doubt they'd even be open
for engineering services like this, hence let's drop the free
advertisement.