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.
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"
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.
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.
Yu Watanabe [Tue, 4 May 2021 05:40:56 +0000 (14:40 +0900)]
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.
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)
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.
Topi Miettinen [Fri, 22 Jan 2021 15:14:50 +0000 (17:14 +0200)]
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.
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.
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.
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.
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.
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.
When watching paths that contain symlinks in some element we so far
always only watched the inode they are pointing to, not the symlink
inode itself. Let's fix that and always watch both. We do this by simply
installing the inotify watch once with and once without IN_DONT_FOLLOW.
For non-symlink inodes this just overrides the same watch twice (where
the second one replaces the first), which is has no effect effectively.
For symlinks it means we'll watch both source and destination.
projects / thirdparty / systemd.git / log
