Then, let's make syslog_parse_identifier() returns PID as pid_t, rather
than the string.
This also makes the function refuse ridiculously long identifier.
Fixes#40456.
Fixes oss-fuzz#477990732 (https://issues.oss-fuzz.com/issues/477990732).
Then, we can drop label_len or label_size arguments at various places.
While doing this, SCM_SECURITY is now ignored when SELinux is disabled
or when it contains embedded NUL.
When udevd received a uevent or inotify event, we will queue or trigger
synthesized events. To minimize the race between processing these events
by udevd and user invocation of 'udevadm settle', let's create /run/udev/queue
file earlier.
On some errors, no event may be queued, but in that case, the file will
be removed by the post event source if nothing queued. See on_post().
Hopefully mitigate the issue #40499.
Otherwise, /run/udev/queue file may be removed before udevd receives
the triggered uevents. This avoids the following race:
1. uevent A is being processed,
2. received an inotify event and trigger a synthesized uevent,
3. uevent A has been processed,
4. the uevent queue becomes empty, and /run/udev/queue is removed,
5. received and queued the synthesized uevent, and /run/udev/queue is recreated.
With this patch, /run/udev/queue is not removed in step 4. Hence,
'udevadm settle' will wait for the synthesized event being processed.
This is similar to waiting for child processes that reread partitions
(thus trigger synthetic events) being terminated, but for synthetic
events triggered by the manager.
When plymouth is enabled, the screen gets all garbled when firstboot
runs and asks questions. Disable the splash screen, but only when
actually asking questions.
unit_file_exists() currently does not follow symlinks, as it is
mainly used to test whether the unit (of any install state)
has been seen under search dirs. However, in ssh-generator
we should search for and honor whatever the distro ships,
which might be an alias or linked externally.
As reported in https://yeswehack.com/vulnerability-center/reports/705270,
YesWeHack issue #YWH-PGM9780-66, if a newline is injected into the message
field, it is passed through unmolested and lands in the .ini file. This
obviously would cause the parser to be confused.
Let's forbid any control characters or quotes in those fields. If we want
something more complicated in the future, we can add a custom validation
function and allow some escaping mechanism.
Unlike other settings that takes multiple values, the setting takes
colon separated list of paths, but when specified as a DBus property,
it previously accepted space separated list of paths.
Let's also make the DBus property accepts colon separated lists.
Fixes#40513.
When machined is started earlier than DBus service, the execution is
blocked by reading properties through DBus for a while. Let's return
earlier if the DBus connection is not ready.
Fixes issue reported in #40414.
When [DHCPPrefixDelegation] Assign=no, networkd creates routes instead of
addresses. These routes need to populate nftables sets for firewall
rules to work correctly.
This commit adds dhcp_pd_route_modify_nft_set() to handle NFT set
updates for DHCP-PD routes, similar to how address_modify_nft_set()
handles them for addresses.
Fixes: #38383
fstab/crypttab generation were moved to the late stage to support
'fixate-volume-key' option. This, however, broke the use-case when
fstab/crypttab are put to the generated partition/image.
Fixes#40444
This is needed to set up extension images from the initrd with
`systemd-sysext --root=/sysroot/ merge`.
- vpick: Don't use openat directly but resolve symlinks in given root
With systemd-sysext --root= all symlinks should be followed relative to
the given root and direct openat usage doesn't work.
Remove the openat call and let pin_choice do the work with the chase
helper function to resolve the symlink in the given root.
- discover-image: Follow symlinks in a given root
So far systemd-sysext with --root= specified didn't follow extension
symlinks (such as the "current" symlinks managed by systemd-sysupdate).
The main use case is running systemd-sysext --root=/sysroot for setting
up the overlay mounts already from the initrd.
Resolve symlinks correctly but don't defend against later symlink races
that would access a path outside of the given root. Malicous live
modifications are not a realistic threat model and anyway for that one
would need to rework how the image entry is passed over up to the point
when the loop device is set up. This change here does not introduce this
weakness nor does it expose it more than before. Thus, make it explicit
that setting up the extensions for a given --root= implies a certain
trust into this given root tree that it does not try do race conditions
with symlinks to trick systemd-sysext to mount a file outside --root=.
Without a strict --image-policy= set we would anyway mount filesystems
right away which is another attack vector but, again, the main use case
is to do this for the final system which is trusted at this stage.
- sysext: Use correct image name for extension release checks
For the extension release check the image name is needed and was derived
from the backing file of the loop device. However, this can have a
different name when symlinks were resolved. The surprising behavior was
that it worked when the target name started with the extension name and
_ because that's what's supported to chop off version suffixes. However,
we should not have such strict requirements for the target name and also
allow - as version separator and entirely different names/prefixes, the
same way as we also do for directories instead of raw images.
Do not use the image name derived from the backing file of the loop
device but directly the extension name we have at hand.
- test: Add tests for handling symlinks with systemd-sysext
When we now allow following symlinks inside a --root= we should also
test that it works in various cases from simple relative and absolute
symlinks to .v being a symlink itself or its contents, both for
directory and for .raw image extensions. While at it, also add a simple
test for .v without symlinks which wasn't there for direct usage of
systemd-sysext.
When link MTU is being adjusted in an IPv6 context (e.g., according to
the MTU received in an RA), the new MTU is clamped against link's
current MTU than link's max MTU. This means that the link MTU can never
be increased via an RA:
systemd-networkd[10068]: eth1: Reducing requested IPv6 MTU 8900 to the interface's maximum MTU 1500.
systemd-networkd[10068]: Setting '/proc/sys/net/ipv6/conf/eth1/mtu' to '1500'
systemd-networkd[10068]: No change in value '1500', suppressing write
Fix this check to make logical sense, and also to match a similar check
in src/network/networkd-setlink.c:link_adjust_mtu().
Commit 15b1c33 ("repart: Generate fstab and crypttab late") moved
fstab/crypttab generation to the late stage but this introduced a regression:
it may be necessary to include fstab and crypttab into the generated partition
(e.g. with CopyFiles=). This is incompatible with 'fixate-volume-key' option as
it is impossible to capture LUKS volume key before it gets created but all the
rest should work fine.
Generate crypttab twice: early and late to capture possible changes. There's no
need to do the same for fstab for now, so keep the status quo.
get_block_device_harder_fd() currently only traverses one level of
device mapper stacking when looking for the underlying block device.
This causes issues with nested DM setups like dm-crypt on top of
dm-integrity, where we don't traverse enough to get the actual physical
device.
Fix this by iterating through all DM layers until we reach a device with
no underlying device. And while we're at it also make cgroups use the
same logic.
Fixes: #40419
The immediate impulse for this change is the fedora scriptlet which called:
/usr/lib/systemd/systemd-update-helper install-system-units cryptsetup-pre.target cryptsetup.target getty@.service ... system-systemd\x2dcryptsetup.slice system-systemd\x2dveritysetup.slice ...
which called
systemctl preset cryptsetup-pre.target cryptsetup.target getty@.service ... system-systemd\x2dcryptsetup.slice system-systemd\x2dveritysetup.slice ...
which threw an error that system-systemdx2dcryptsetup.slice does not exist
and did nothing at all. (The backslash is consumed by the shell.)
The obvious fix here is to figure out more levels of escaping… But we should
do something more robust in such cases.
If we fail in processing of a single unit, let preset all continue processing
units, report the failure through 'changes'. At the end, return failure. In
general, for operations which operate on a list of units specified by the user,
fail the whole operation if any of the individual operations failed. The only
operation where we don't do this is 'preset-all'.
$ SYSTEMD_LOG_LEVEL=debug build/systemctl --root=/ preset asdf1.servie asdf2.path; echo $?
Cannot find unit asdf1.servie.service.
Cannot find unit asdf2.path.
Failed to preset unit: Unit asdf1.servie.service does not exist
Failed to preset unit: Unit asdf2.path does not exist
1
While at it, fix double logging in the manager: dump_unit_changes() already
logs about errors, so the manager should only log on success.
This partially reverts a4f0e0da35. The
intent was good, we gather the errors, but we have no mechanism to
propagate the result, so the gathered result was ignored. In 'changes'
we can only report errors for specific units. If reading of the
directory fails, we might just as well report the error immediately.
This isn't great, but it's better then ignoring the errors. In practice,
failing halfway in this manner is unlikely, since it'd mean that the fs
is corrupted or something like that. We might as well return immediately
on such catastrophic errors.
archive_read_header(3) states that `archive_read_next_header()` returns
`ARCHIVE_WARN` if it succeeds but a non-critical error is found, so issue a
warning instead of stopping the untar process in this case.
The current code assumes that FILEID_KERNFS filehandles will never grow
in size. This is not a safe assumption and userland shouldn't be trying
to guess the size of the filehandle it'll get.
We have a macro for that: MAX_HANDLE_SZ.
For the extension release check the image name is needed and was derived
from the backing file of the loop device. However, this can have a
different name when symlinks were resolved. The surprising behavior was
that it worked when the target name started with the extension name and
_ because that's what's supported to chop off version suffixes. However,
we should not have such strict requirements for the target name and also
allow - as version separator and entirely different names/prefixes, the
same way as we also do for directories instead of raw images.
Do not use the image name derived from the backing file of the loop
device but directly the extension name we have at hand.
So far systemd-sysext with --root= specified didn't follow extension
symlinks (such as the "current" symlinks managed by systemd-sysupdate).
The main use case is running systemd-sysext --root=/sysroot for setting
up the overlay mounts already from the initrd.
Resolve symlinks correctly but don't defend against later symlink races
that would access a path outside of the given root. Malicous live
modifications are not a realistic threat model and anyway for that one
would need to rework how the image entry is passed over up to the point
when the loop device is set up. This change here does not introduce this
weakness nor does it expose it more than before. Thus, make it explicit
that setting up the extensions for a given --root= implies a certain
trust into this given root tree that it does not try do race conditions
with symlinks to trick systemd-sysext to mount a file outside --root=.
Without a strict --image-policy= set we would anyway mount filesystems
right away which is another attack vector but, again, the main use case
is to do this for the final system which is trusted at this stage.
Yu Watanabe
Luca Boccassi
Antonio Alvarez Feijoo
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Govind Venugopal
Ivan Shapovalov
Vitaly Kuznetsov
Lennart Poettering
Kai Lüke
Jeff Layton
Kai Lueke