| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Check for flags with FLAGS_SET() where possible.
|
|
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.
|
|
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.
|
|
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".
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
Makes the silent flags behavior consistent between regular password
entry and FIDO2 pin entry.
|
|
|
|
|
|
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"
|
|
gracefully
|
|
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.
|
|
Also, drop redundant check for has_client_pin, which can never happen,
since we already filtered this case a bit further up.
|
|
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 fixes a bug introduced by e8630e695232bdfcd16b55f3faafb4329c961104.
Fixes CID#1453292.
|
|
Fixes CID#1453294.
|
|
Fixes CID#1453293.
|
|
|
|
|
|
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.
|
|
|
|
|
|
The previous commit about path_compare() breaks chase_symlinks().
This commit fixes it.
|
|
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.
|
|
This also makes the function checks the result is a valid path or not.
|
|
This makes path_startswith() stricter. If one of the path component in
arguments is longer than NAME_MAX, it returns NULL.
|
|
|
|
The function is similar to path_is_valid(), but it refuses paths which
contain ".." component.
|
|
|
|
The function may be useful to iterate on each path component.
|
|
|
|
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
|
|
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)
|
|
This is not a comprehensive port, but mostly some low-hanging fruit.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This is an option, not a command.
|
|
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).
|
|
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).
|
|
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.
|
|
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.
|
