This service's job is to talk to a VM associated IMDS service provided
by the local Cloud. It tries to abstract the protocol differences
various IMDS implementations implement, but does *not* really try to
abstract more than a few basic fields of the actual IMDS metadata.
IMDS access is wrapped in a Varlink API that local clients can talk to.
If possible this makes use of the IMDS endpoint information that has
been added to hwdb in the preceeding commit. However, endpoint info can
also be provided via kernel command line and credentials. For debugging
purposes we also accept them via environment variables and command line
arguments.
This adds a concept of early-boot networking, just enough to be able to
talk to the IMDS service. It is minimally configurable via a kernel
cmdline option (and a build-time option): the user may choose between
"locked" and "unlocked" mode. In the former mode direct access to IMDS via
HTTPS is blocked via a prohibit route (and thus all IMDS communication
has to be done via systemd-imdsd@.service). In the latter case no such
lockdown takes place, and IMDS may be acquired both via this new service
and directly. The latter is typically a good idea for compatibility with
current systems, the former is preferable for secure installations.
Access to IMDS fields is controlled via PK.
This is an another alternative for #40656, based on @poettering's
suggestion to use an ELF section.
The output of --help is generated using format-table, but the details of
the formatting a bit off: different sections in the table (verbs, option
groups) are not aligned to the same column. Our current table formatting
doesn't make this easy. If somebody has an idea how to do this without
too much pain, please make suggestions.
Another thing that I didn't know how to do nicely, was to use the two
columns of separation. But maybe this doesn't matter. If we switch to
one column everywhere, I don't think people will care.
Example output:
```console
$ build/systemd-id128 -h | cat
systemd-id128 [OPTIONS...] COMMAND
Generate and print 128-bit identifiers.
Commands:
new Generate a new ID
machine-id Print the ID of current machine
boot-id Print the ID of current boot
invocation-id Print the ID of current invocation
var-partition-uuid Print the UUID for the /var/ partition
show [NAME|UUID] Print one or more UUIDs
help Show this help
Options:
-h --help Show this help
--version Show package version
--no-pager Do not start a pager
--no-legend Do not show headers and footers
--json=FORMAT Output inspection data in JSON (takes one of pretty,
short, off)
-j Equivalent to --json=pretty (on TTY) or --json=short
(otherwise)
-p --pretty Generate samples of program code
-P --value Only print the value
-a --app-specific=ID Generate app-specific IDs
-u --uuid Output in UUID format
See the systemd-id128(1) man page for details.
```
The output wraps automatically with terminal width. If the terminal is
extremely narrow, ellipsization occurs. I think this doesn't matter
and/or is actually a feature. Such narrow terminals mostly occur in
testing, so it doesn't matter what exactly we do, as long as it is
something somewhat reasonable.
Anyway, I think this is enough as PoC. Please compare this with the
previous approach. /cc @behrmann, @YHNdnzj, @poettering
The three binaries that are converted have options, verbs, optional
arguments, and options terminate option parsing, so most of the
functionality is there. One thing that I didn't implement that was
present in previous PRs is "namespaces", i.e. multiple parsers in the
same source file. I expect that we can handle this similarly to option
groups.
The behaviour that was implemented in systemd-dissect was that
both '--exec -- cmd' and '--exec cmd' result in 'cmd' as the command,
and '--' anywhere later is as a positional argument, so nesting is
possible, e.g.:
--exec -- cmd --opt -- another-cmd --another-opt
This is not obvious, so add some tests for this and keep it as a separate
commit.
Add tests for OPTION_STOPS_PARSING, OPTION_GROUP_MARKER, and
OPTION_OPTIONAL_ARG flags with manual Option arrays, and a separate
test exercising the OPTION, OPTION_LONG, OPTION_SHORT, OPTION_FULL,
and OPTION_GROUP macros via FOREACH_OPTION_FULL in a switch statement,
as they would be used in real code.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
The test cases are the same in both files. To make the test
more through, add case where "--" is used more than once and
also when options are present after "--".
Typically, the top-level JSON object has to be an object, in any json
document we parse, hence let's add a simple way to enforce that.
Make use of this in various places.
(Note, various other JSON parsers insist on this logic right from the
beginning, but I actually thinking making this insisting optional like
this patch does it is the cleaner approach)
This is very similar to write_string_file_atomic(), but is intentionally
kept separate (after long consideration). It focusses on arbitrary
struct iovec data, not just strings, and hence also doesn't do stdio at
all. It's hence a lot more low-level.
We might want to consider moving write_string_file*() on top of
write_data_file_atomic_at(), but for now don't.
This file was a bit strange… It was shoehorning a manual test into
the intro block and not using the rest of the TEST machinery. Let's
convert it into a normal executable with a run function as we do
in other similar cases.
Fixup for 514fa9d39a. We are now getting
failures in CI i386 builds in Fedora rawhide:
TZ=Europe/Lisbon, tzname[0]=WET, tzname[1]=WEST
@212545617716594 → Sun 1976-09-26 00:26:57 WET → @212542017000000 → Sun 1976-09-26 00:26:57 CET
src/test/test-time-util.c:450: Assertion failed: Expected "ignore" to be true
Restore the conditionalization for CAT, EAT, WET that was removed
in the refactoring.
Add an optional field that can be used to store a user's birth date.
userdb already stores personal metadata (`emailAddress`, `realName`,
`location`) so `birthDate` is a natural fit.
Add a birthDate field to the JSON user record, stored internally as a
struct tm with INT_MIN/negative sentinels for unset fields. The field
is serialized as a YYYY-MM-DD string in JSON and validated via
parse_birth_date(), which shares its core logic with
parse_calendar_date() through a new parse_calendar_date_full()
function.
For birth dates, timegm() is called directly (rather than
mktime_or_timegm_usec) to support pre-epoch dates. The wday field is
used to distinguish timegm() failure from a valid (time_t) -1 return.
birthDate is excluded from user_record_self_modifiable_fields(), so
only administrators can set or change it via homectl. The field
remains in the regular (non-privileged) JSON section, keeping it
readable by the user and applications.
We often have a pattern where the same verb function is used for
multiple actions. This leads to an antipattern where we figure out what
action needs to be taken from argv[0] multiple times: often once in
arse_argv() to figure out what options are allowed, then once again
implicitly in dispatch_verb(), and then again in the action verb itself.
Let's allow passing a parameter into the verb to simplify this.
Move the YYYY-MM-DD date parsing and validation logic from
sysupdate-resource.c into a shared parse_calendar_date() function
in time-util, so it can be reused by other subsystems.
The SYSTEMD_COLORS=true/1/yes no longer forced colors
when stdout was not a TTY (e.g. piped), because the COLOR_TRUE bypass
of the terminal_is_dumb() check was accidentally dropped.
Restore the old behavior by guarding the TTY check with
`m != COLOR_TRUE`, so an explicit boolean "true" value continues to
unconditionally force color output regardless of whether stdout is a TTY
or whether $NO_COLOR is set.
We often have a pattern where the same verb function is used for
multiple actions. This leads to an antipattern where we figure out what
action needs to be taken from argv[0] multiple times: often once in
parse_argv() to figure out what options are allowed, then once again
implicitly in dispatch_verb(), and then again in the action verb itself.
Let's allow passing a parameter into the verb to simplify this.
This matches a pattern we have in conf-parser.h, where we have both
void *userdata (more global) and void *data (per-config item). Here,
I opted for uintptr_t userdata. It seems that most of the time we'll
want to just pass an enum value. This works OK with no casts. I also
tried a void* and union. In both cases, much more boilerplate is needed:
either a cast or a macro to help avoid compiler warnings. uintptr_t
seems generic enough to cover foreseeable usecases with no fuss.
This is a noop refactoring. See next commit for an example.
Suppress warnings like the following from clang tidy:
```
../src/boot/addon.c:11:19: error: function 'efi_main' can be made static to enforce internal linkage [misc-use-internal-linkage,-warnings-as-errors]
11 | EFIAPI EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *system_table);
| ^
```
Some warnings are suppressed simply by setting comments to ignore the warning,
some are by making global variables static, or include a suitable header.
The old name suggested this would only check if the two inodes are on
the same mount, but it actually checks if they are the same inodes too.
Let's rename it to make this clearer, in particular as we have
both statx_inode_same() and statx_mount_same() already, and they are
even used here, and hence very confusing.
This also drops two checks from the test case, which are simply wrong.
Given they apparently weren't load bearing (since no CI tripped up),
let's just drop them.
Add the missing 'mstack' value to the ImageType enum in the
io.systemd.sysext Varlink IDL — image_type_table in discover-image.c
already defines IMAGE_MSTACK = "mstack" but it was absent from the IDL.
Export vl_type_ImageType so the test can reference it, and add
TEST_IDL_ENUM(ImageType, ...) to the enums_idl test to catch
similar regressions in the future.
We want to support the scenario where we bind mount the nsresourced
varlink socket into a container to allow nested containers where the
outer container runs in its own transient range from nsresourced but
can still allocate transient ranges for its own nested containers.
To support this use case let's add support for delegation. Delegated
ranges are allocated when allocating the primary range and are propagated
1:1 to the user namespace. We track delegated ranges in ".delegate" files
in the userns registry so that they can't be used for other range allocations.
We make one exception for delegated ranges though, if we get a request from
a user namespace that is a child of the user namespace that owns the delegated
ranges, we allow allocating from the delegated range. The parent userns already
has full ownership over the child userns, so it doesn't matter that the parent
userns and the child userns share the same range. This allows making use of
delegated ranges without having to run another copy of nsresourced inside the
parent userns to hand out from the delegated range.
To support recursive delegations, we keep track of the previous owners of the
delegated range and restore ownership to the last previous owner when the current
owner is freed.
This introduces PinnedResources as a structure combining pinned
references to a root directory, root image, or root mstack. This is not
only easier to work with, but essential to make certain unpriv things
work, as we need some mechanism to pin resources before we drop into a
userns which might possibly not provide access anymore to those
resources.
Hence this does two things: introduce the new structure, and immediately
hook it up so that we pin things properly before dropping into userns,
and then makes use of this after dropping the right way, and enables
unpriv userns operation.
The concept is generic enough to eventually implement extension images +
mount images with the same structure, but in order to keep the changes
managable this is left for another time.
(This also makes one further clean-up: client-side verity-reuse checks
are moved server side if we are unpriv. Previously we'd do them client
side, but they were doomed to fail because of lack of privs. Hence let's
drop the client side if we are unpriv and purely do them server-side in
that case.)
So far we opened a new Varlink connection for every mountfsd/nsresourced
method call. Given each tool only does a very small number of calls
(usually 1…5) on them and the connections are cheap this is not too
wasteful. Nonetheless, let's do something about it, and allow reusing
the connection for multiple calls.
This not only makes things a bit more efficient, but has one more
important benefit: Varlink connections pin the security context of the
client when connecting. This means that varlink method calls done with a
connection established while some code was privileged will still operate
as privieged once privs are dropped, until the connection is closed.
This pinning effect is really nice, as it gives us behaviour in a
"capability system" like scheme. Later code is going to use that to
continue doing certain priv userns ops even after unsharing userns and
becoming fully unpriv.
This was made a strv to handle either directories or raw images but
since we now handle that via multiple PickFilter instances, we don't
need suffixes to be a strv anymore.
Once we start measuring Verity volumes as we activate them we want to
include information about the signature keys used, so that we can have
distinct ones for confext and for sysext and ther purposes and thus have
a cryptograpically protected hint about the kind of image we have
activated in the event log.
Ideally we'd measure a fingerprint of the signing certificate here, but
we don't have that here typically (as PKCS7 signatures used here
typically do not embed that), hence use the next best thing: the issuer
name and the serial number.
These were introduced as part of the effort of sd-executor
worker pool (#29566), which never landed due to unsignificant
performance improvement. Let's just remove the unused
helpers. If that work ever gets resurrected they can be
restored from this commit pretty easily.
There's no need to pass in a boolean to decide whether we use
namespace_enter_delegated() or not. Instead, we can just check if we
have CAP_SYS_ADMIN in our own user namespace. If we don't, then we have
to insist on a child user namespace being passed in and we have to enter
it first to get CAP_SYS_ADMIN as without CAP_SYS_ADMIN we wouldn't be able
to call setns() in the first place. If we do have CAP_SYS_ADMIN, we can
always enter the other namespaces first before entering the user namespace.
Additionally, we don't fail anymore if we can't reset the UID/GID since a
root user might not always be available in every user namespace we might
enter.