Inspired by #25664: let's check explicitly for NULL everywhere we do one
of those getXYZcon() calls.
We usually turn this into EOPNOTSUPP, as when selinux is off (which is
supposed to be the only case this can happen according to selinux docs)
we otherwise return EOPNOTSUPP in that case.
Note that in most cases we have an explicit mac_selinux_use() call
beforehand, hence this should mostly not be triggerable codepaths.
This effectively reverts 5d0030310c.
With the commit 5d0030310c, networkd manages
addresses with the detailed hash and compare functions. But that causes
networkd cannot detect address update by the kernel or an external tool.
See issue
https://github.com/systemd/systemd/issues/481#issuecomment-1328132401.
With this commit, networkd (again) manages addresses in the way that the
kernel does. Hence, we can correctly detect address update.
It may take a bit for newly introduced binaries/other files to get
properly integrated into the Rawhide specfile, so don't choke up in the
meantime when rpmbuild detects unpackaged files.
Systemd documents "halt" as the primary shutdown mechanism, redirecting
"reboot" and "shutdown" to the halt(8), but halt is a really strange and
obsolete concept. Who would want to really keep their machine running after
shutdown? I expect that halting is almost unused. Let's at least make it less
prominent in the docs.
While at it, use "power off" for a verb and "power-off" for noun (but "poweroff"
of the actual command name).
Follow-up for 719b7d4dc2.
The size of the current reproducer is 250KB. Hence, 16KB should be
enough, but still we can test most arguments within the size.
Hopefully fixes oss-fuzz#53552.
When an interface goes to down, the kernel drops several routes
automatically, and at the same time networkd requests to remove
them, but the kernel sometimes does not respond the requests. Hence,
the routes cannot drop the REMOVING flag, and networkd will never try
to configure other routes which depend on the previously removed
routes even if they are already reconfigured.
With this patch, when networkd sends a request to configure a route
(or any other network settings), REMOVING flag for the route is dropped
without waiting for the reply about the previous remove request, as we
can expect it will appear even if it is already removed or under removing.
Fixes#24999.
I'd like to use this as a basis for an exitrd:
When compiled with -Dstandalone-binaries=true -Db_lto=true -Dbuildtype=release,
the new file is 800k. It's more than I'd like, but still quite a bit less
than libsystemd-shared.so, which is 3800k.
- rename function arguments for storing results, and support the case
that they are NULL,
- return earlier on error,
- always validate read size in efivar_get_uint32_le() and efivar_get_uint64_le().
The journal has a mechanism to log to the runtime journal if it fails to
log to the system journal. This mechanism is not triggered when the file
system becomes read-only. We enable it here.
When appending an entry fails if shall_try_append_again returns true,
the journal is rotated. If the FS is read-only, rotation will fail and
s->system_journal will be set to NULL. After that, when find_journal
will try to open the journal since s->system_journal will be NULL, it
will open the runtime journal.
Before we supported pivot_root() nspawn used to make the rootfs shared
before setting up the mount tunnel. So it was safe for it to just turn
it into a dependent mount during setup.
However, we cannot do this anymore because of the requirements
pivot_root() has. After the pivot_root() we will make the rootfs shared
recursively. If we turned the mount tunnel into dependent mount before
mount_switch_root() this will have the consequence that it becomes a
shared mount within the same peer group as the rootfs. So no mounts will
propagate into the container from the host anymore.
To fix this we split setting up the mount tunnel and making it active
into two steps. Setting up the mount tunnel is performed before
mount_switch_root() and activating it afterwards. Note that this works
because turning a shared mount into a shared mount is a nop. IOW, no new
peer group will be allocated.
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>