CodeQL was complaining that the local variable obscurs the global
one. It is indeed a bit confusing when reading this… Let's rename
the variable to avoid confusing the reader.
Confer https://github.com/systemd/systemd/pull/19006#issuecomment-800234022:
On some systems it's the admin's explicit choice not to to have the
machine ID leak into the ESP
On some systems the machine ID is transient, generated at every boot,
and hence should not be written to the ESP
Follow-up for pull request #21170.
I hoped that we would drop libgcrypt fully and drop all references to the
library in meson, but this doesn't seem feasible (because of the use in
sd-journal). But let's remove it here, all the resolved code has been switched
to work either of the two libraries.
When an activation job is skipped because of a Condition*= setting failing,
currently the JobRemoved signal lists 'done' as the result, just as with
a successful job.
This is a problem when doing dbus activation: dbus-broker will receive a
signal that says the job was successful, so then it moves into a state where
it waits for the requested name to appear on the bus, but that never happens
because the job was actually skipped.
Add a new StartUnitWithFlags that changes the behaviour of the JobRemoved
signal to list 'done' or 'skipped'.
Fixes#21520
This removes the DNS_SERVER_FEATURE_LEVEL_LARGE, and sets the EDNS0
advertised max packet size as if always in 'large' mode.
Without this, we always send out EDNS0 opts that limit response sizes
to 512 bytes, thus the remote server will never send anything larger
and will always truncate responses larger than 512 bytes, forcing us
to drop from EDNS0 down to TCP, even though one of the primary benefits
of EDNS0 is larger packet sizes.
Fixes: #20993
`link_is_ready_to_configure()` is used to judge we can configure
addresses, routes, and etc. And they can be configured independently of
stacked netdevs.
Programs run by udev triggers may need to execute the bpf() syscall. Even more
so, since on a cgroup v2 system, the only way to set up device access filtering
is to install a BPF program on the cgroup in question and one way of passing
data to such program is through BPF maps, which can only be access using the
bpf() syscall. One such use case was identified in RHBZ#2025264 related to
snap-device-helper, and led to RHBZ#2027627 being filed.
Unfortunately there is no finer grained control over what gets passed in the
syscall, so just enable bpf() and leave fine grained mediation to other
security layers (eg. SELinux).
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2027627
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
People often assigns the MAC address of the enslaved interface to e.g.
bridge interface. So, the local assignment bit should not be adjusted.
Fixes#21649.
Zbigniew Jędrzejewski-Szmek
наб
Yu Watanabe
James Hilliard
Luca Boccassi
Frantisek Sumsal
Jan Macku
Dan Streetman
Evgeny Vereshchagin
Maciek Borzecki