This has the side effect to upgrade the log level at which the log is emitted
from debug to warning.
This might be better since after all we didn't apply a tmpfiles.d/ rule and
that actually might end up being problematic eventually.
We're always interested into finding unsafe transitions so let's make the
helper return true when it finds such transitions so we don't need to negate
its results.
No functional changes.
and let's emit a more comprehensive warning when an unsafe transition is
encountered.
Before this patch:
Unsafe symlinks encountered in /run/nrpe, refusing.
After:
Detected unsafe path transition / → /run during canonicalization of /run/nrpe.
We previously returned -EPERM but it can be returned for various other reasons
too.
Let's use -ENOLINK instead as this value shouldn't be used currently. This
allows users of CHASE_SAFE to detect without any ambiguities when unsafe
transitions are encountered by chase_symlinks().
All current users of CHASE_SAFE that explicitly reacted on -EPERM have been
converted to react on -ENOLINK.
This flag can be used to make chase_symlinks() emit a warning when it
encounters an error.
Such flag can be useful for generating a comprehensive and detailed warning
since chase_symlinks() can generate a warning with a full context.
For now only warnings for unsafe transitions are produced.
add new "systemd-run-generator" for running arbitrary commands from the kernel command line as system services using the "systemd.run=" kernel command line switch
Otherwise, some tests may disturb others, e.g.,
NetworkdNetWorkTests.test_routing_policy_rule_port_range and
NetworkdNetWorkTests.test_routing_policy_rule.
This switches the RFC3704 Reverse Path filtering from Strict mode to Loose
mode. The Strict mode breaks some pretty common and reasonable use cases,
such as keeping connections via one default route alive after another one
appears (e.g. plugging an Ethernet cable when connected via Wi-Fi).
The strict filter also makes it impossible for NetworkManager to do
connectivity check on a newly arriving default route (it starts with a
higher metric and is bumped lower if there's connectivity).
Kernel's default is 0 (no filter), but a Loose filter is good enough. The
few use cases where a Strict mode could make sense can easily override
this.
The distributions that don't care about the client use cases and prefer a
strict filter could just ship a custom configuration in
/usr/lib/sysctl.d/ to override this.
DNS_PACKET_PAYLOAD_SIZE_MAX is limiting the size of the stub replies to
512 with EDNS off or 4096 with EDNS on, without checking the protocol
used. This makes TCP replies for clients without EDNS support to be
limited to 512, making the truncate flag useless if the query result is
bigger than 512 bytes.
This commit increases the size of TCP replies to DNS_PACKET_SIZE_MAX
Fixes: #10816
Previously, we'd link the unit file into /etc in this case, but that
should only be done if the unit file is not in the search path anyway,
and this is already done implicitly anyway for all enabled unit files,
hence no reason to duplicate this here.
Fixes: #10253
Quite often when we generate objects some fields should only be
generated in some conditions. Let's add high-level support for that.
Matching the existing JSON_BUILD_PAIR() this adds
JSON_BUILD_PAIR_CONDITIONAL() which is very similar, but takes an
additional parameter: a boolean condition. If "true" this acts like
JSON_BUILD_PAIR(), but if false then the whole pair is suppressed.
This sounds simply, but requires a tiny bit of complexity: when complex
sub-variants are used in fields, then we also need to suppress them.
New features are constantly added to networkd. Apparently, not everybody
knows that the "directives" files should be updated too to make
the fuzzers aware of them.
Not sure how I missed this, but we of course need to wait for the
"systemd-run" commands to finish before we can check the output files
this generated.
