Add a new option PrivateBPF= to mount a new instance of bpffs within a
namespace.
PrivateBPF= can be set to "no" to use the host bpffs in readonly mode
and "yes" to do a new mount.
The mount is done with the new fsopen()/fsmount() API because in future
we'll hook some commands between the two calls.
For some fields, we perform careful parsing and verification on the sender
side. For other fields, we accept any string or strv. I think that actually
this is fine: we should optimize for the correct case, i.e. the user runs a
command that is valid. The server must perform parsing in all cases, so doing
the verification on the sender side doesn't add value. When doing parsing
locally, in case of invalid or unsupported input, we would generate the error
message locally, so we would avoid the D-Bus call, but the message itself is
not better and from the user's point of view, the result is the same. And by
doing the parsing only on the server side, we deal better with the case where
the sender has an older version of the software. By not doing verification, we
implicitly "support" new values. And when the sender has a newer version that
supports additional fields, that does not help as long as the server uses an
older version. So in case of version mismatches, parsing on the server side is
as good or better.
Resolves https://github.com/systemd/systemd/issues/37174.
This changes little in behaviour, the conceptual part is more important. The
non-Ex variant is the actual name on the command line, and we should use the
non-Ex D-Bus property too, if it works. This increases compatibility with old
versions. But the code was mostly doing the right thing. Even the tests tested
the right thing.
Follow-up for b3d593673c and
898fc00e79.
The test is simplified by taking advantage of the fact that both names
on the commandline are supposed to behave identically.
Partially resolves https://github.com/systemd/systemd/issues/37174.
We generally want to have error messages with a fixed structure that convey the
important information, i.e. field name, error value, and the offending text for
options that take short values. (The text is not printed for strings encoded with
base64 and hexmem or for credentials.)
Let's use a helper that prints the message in a fixed format in the majority of
cases. In the few places where a custom message is useful, the helper is not
used. The helper:
- prints the field name, value, and error info,
- quotes the value,
- handles -ENOMEM, so we don't need to handle it separately everywhere.
When this code was originally written, parse functions would return -1
as error. Nowadays day all return a good errno, so it is fine if we print
the corresponding strerror.
exec_command_flags_to_strv() should not fail, unless we screwed up, so assert
instead of returning an error. Also, no need to strdup constant _PATH_BSHELL;
drop that so that we can get rid of the oom error handling. Finally, rename
l → cmdline for clarity.
Before, for empty input, we'd send an array with one item with an empty
pattern. Use the helper which sends an empty array instead.
bus_exec_context_set_transient_property() ignores items with an empty
pattern, so the result should be the same.
Request in review:
https://github.com/systemd/systemd/pull/37665#discussion_r2182375988.
Those are user-controlled strings, so let's use heap allocations in the usual
fashion. (Though, with strndupa_safe, the allocations were bounded anyway, so
ultimately this doesn't matter.)
bus_append_unit_property() and associated functions accept a long list of
properties. But the specific names are only available through code. But it is
useful to be able to know the specific list of properties that is supported, in
particular for shell completions. Thus, add a way to list the properties that
are supported by the code.
In the future we could also turn this into a test for the documentation. For
various reasons, the list of properties listed in the docs is a partially
overlapping set. E.g. for service type, the pull request
https://github.com/systemd/systemd/pull/37661 creates a list with 212 entries,
and this code generates 7 entries less and 184 more. I didn't check all the
differences, but in the few cases I did, the list generated here was actually
correctly supported by 'systemd-run -p'.
A smoke test is added.
As with grandparent commit for ImportCredentialEx=, the whole series of commits
that extended ProtectHostname was confused (6746f28854,
cf48bde7ae, e76fcd0e40),
because it added ProtectHostnameEx in places where parsing of ProtectHostname
should be have been extended.
Accept ProtectHostname=… with the new extended syntax, keep accepting
ProtectHostnameEx=… for compat with release v257. Prefer sending ProtectHostname.
Partially resolves https://github.com/systemd/systemd/issues/37174.
We add D-Bus properties like "*Ex" because we cannot change the D-Bus property
type without breaking backward comapatibility. But those names are only for
D-Bus, not for config file stanzas or the command-line parser. There, we can
change the type, or in other words, there is no type, just a free-form string
whose interpretation we can extend or change. Commit
831f208783 that added ProtectHostnameEx was
confused, because it added ImportCredentialEx in places where parsing of
ImportCredential should be have been extended.
On D-Bus, we send ImportCrednential in preference, and ImportCredentialEx only
when required. This way we send less bytes on the wire and support older
systems that don't understand the new property.
Partially resolves https://github.com/systemd/systemd/issues/37174.
