This is not applicable to the v255-stable branch, and it breaks a unit
test:
1287/1652 systemd:dist / check-version-history FAIL 1.62s exit status 1
This reverts commit d73cf4cf06.
The check looks plausible, but when I started checking whether it needs
to be lowered for the recent changes, I realized that it doesn't make
much sense.
context_parse_iovw() is called from a few places, e.g.:
- process_socket(), where the other side controls the contents of the
message. We already do other checks on the correctness of the message
and this assert is not needed.
- gather_pid_metadata_from_argv(), which is called after
inserting MESSAGE_ID= and PRIORITY= into the array, so there is no
direct relation between _META_ARGV_MAX and the number of args in the
iovw.
- gather_pid_metadata_from_procfs(), where we insert a bazillion fields,
but without any relation to _META_ARGV_MAX.
Since we already separately check if the required stuff was set, drop this
misleading check.
(cherry picked from commit 13902e0253)
(cherry picked from commit 4c424072b3)
See the comment in the patch for details.
Suggested-by: Qualys Security Advisory <qsa@qualys.com>
(cherry-picked from 8fc7b2a211)
(cherry-picked from 101058955e)
The kernel provides %d which is documented as
"dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE".
We already query /proc/pid/auxv for this information, but unfortunately this
check is subject to a race, because the crashed process may be replaced by an
attacker before we read this data, for example replacing a SUID process that
was killed by a signal with another process that is not SUID, tricking us into
making the coredump of the original process readable by the attacker.
With this patch, we effectively add one more check to the list of conditions
that need be satisfied if we are to make the coredump accessible to the user.
Reportedy-by: Qualys Security Advisory <qsa@qualys.com>
(cherry-picked from 0c49e0049b)
(cherry-picked from c58a8a6ec9)
No functional change. This change is done in preparation for future changes.
Currently, the list of fields which are received on the command line is a
strict subset of the fields which are always expected to be received on a
socket. But when we add new kernel args in the future, we'll have two
non-overlapping sets and this approach will not work. Get rid of the variable
and enumerate the required fields. This set will never change, so this is
actually more maintainable.
The message with the hint where to add new fields is switched with
_META_ARGV_MAX. The new order is more correct.
(cherry-picked from 49f1f2d4a7)
(cherry-picked from aea6a631bc)
The -vv parameter was added in version 2.7, check before using it
Follow-up for ebc0514a65
(cherry picked from commit 60491ceb12)
(cherry picked from commit f75ca4648e)
It fails on this branch, and nobody knows how to fix it:
'Cannot create a new Copr project (owner=packit project=systemd-systemd-37643 chroots=[]): chroots: '[]' is not a valid choice for this field..'
Disable it, as it just generates noise
Follow-up for 52e3671bf7
unit_gc_sweep() might try to add the unit to gc queue again.
While that becomes no-op as Unit.in_gc_queue is not cleared
yet, it induces minor inconsistency of states.
(cherry picked from commit 741a184a31)
(cherry picked from commit 9645e946f9)
iproute2 v6.15 fixed some rounding errors in the reported stats:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=d947f365602b30657d1b797e7464000d0ab88d5a
so the current regex doesn't work anymore. Fix it to check for both
old and new values.
systemd-networkd-tests.py[523]: FAIL: test_qdisc_tbf (__main__.NetworkdTCTests.test_qdisc_tbf)
systemd-networkd-tests.py[523]: ----------------------------------------------------------------------
systemd-networkd-tests.py[523]: Traceback (most recent call last):
systemd-networkd-tests.py[523]: File "/usr/lib/systemd/tests/testdata/test-network/systemd-networkd-tests.py", line 5402, in test_qdisc_tbf
systemd-networkd-tests.py[523]: self.assertRegex(output, 'rate 1Gbit burst 5000b peakrate 100Gbit minburst 987500b lat 70(.0)?ms')
systemd-networkd-tests.py[523]: ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
systemd-networkd-tests.py[523]: AssertionError: Regex didn't match: 'rate 1Gbit burst 5000b peakrate 100Gbit minburst 987500b lat 70(.0)?ms' not found in 'qdisc tbf 35: root refcnt 2 rate 1Gbit burst 5000b peakrate 100Gbit minburst 999200b lat 70ms \nqdisc pfifo 37: parent 35: limit 100000p'
(cherry picked from commit f9a85b7490)
(cherry picked from commit 6e67969b10)
Let's make this easier to debug. (When this failed for me due to disk
full it took me a bit to figure out what was going on.)
(cherry picked from commit 5b759bf5fd)
(cherry picked from commit 8158c87c36)
The old description makes users wrongly assume that the cap of 4G
applied, even when the user specifies a value that will result in higher
than 4G. This commit avoids this misunderstanding.
(cherry picked from commit 3308414531)
(cherry picked from commit 137d765b2d)
This was broken in f45b801551. Unfortunately
the review does not talk about backward compatibility at all. There are
two places where it matters:
- During upgrades, the replacement of kernel.core_pattern is asynchronous.
For example, during rpm upgrades, it would be updated a post-transaction
file trigger. In other scenarios, the update might only happen after
reboot. We have a potentially long window where the old pattern is in
place. We need to capture coredumps during upgrades too.
- With --backtrace. The interface of --backtrace, in hindsight, is not
great. But there are users of --backtrace which were written to use
a specific set of arguments, and we can't just break compatiblity.
One example is systemd-coredump-python, but there are also reports of
users using --backtrace to generate coredump logs.
Thus, we require the original set of args, and will use the additional args if
found.
A test is added to verify that --backtrace works with and without the optional
args.
(cherry picked from commit ded0aac389)
(cherry picked from commit f9b8b75c11)
This returns to the original approach proposed in
https://github.com/systemd/systemd/pull/17270. After review, the approach was
changed to use sd_pid_get_owner_uid() instead. Back then, when running in a
typical graphical session, sd_pid_get_owner_uid() would usually return the user
UID, and when running under sudo, geteuid() would return 0, so we'd trigger the
secure path.
sudo may allocate a new session if is invoked outside of a session (depending
on the PAM config). Since nowadays desktop environments usually start the user
shell through user units, the typical shell in a terminal emulator is not part
of a session, and when sudo is invoked, a new session is allocated, and
sd_pid_get_owner_uid() returns 0 too. Technically, the code still works as
documented in the man page, but in the common case, it doesn't do the expected
thing.
$ build/test-sd-login |& rg 'get_(owner_uid|cgroup|session)'
sd_pid_get_session(0) → No data available
sd_pid_get_owner_uid(0) → 1000
sd_pid_get_cgroup(0) → /user.slice/user-1000.slice/user@1000.service/app.slice/app-ghostty-transient-5088.scope/surfaces/556FAF50BA40.scope
$ sudo build/test-sd-login |& rg 'get_(owner_uid|cgroup|session)'
sd_pid_get_session(0) → c289
sd_pid_get_owner_uid(0) → 0
sd_pid_get_cgroup(0) → /user.slice/user-0.slice/session-c289.scope
I think it's worth checking for sudo because it is a common case used by users.
There obviously are other mechanims, so the man page is extended to say that
only some common mechanisms are supported, and to (again) recommend setting
SYSTEMD_LESSSECURE explicitly. The other option would be to set "secure mode"
by default. But this would create an inconvenience for users doing the right
thing, running systemctl and other tools directly, because then they can't run
privileged commands from the pager, e.g. to save the output to a file. (Or the
user would need to explicitly set SYSTEMD_LESSSECURE. One option would be to
set it always in the environment and to rely on sudo and other tools stripping
it from the environment before running privileged code. But that is also fairly
fragile and it obviously relies on the user doing a complicated setup to
support a fairly common use case. I think this decreases usability of the
system quite a bit. I don't think we should build solutions that work in
priniciple, but are painfully inconvenient in common cases.)
Fixes https://yeswehack.com/vulnerability-center/reports/346802.
Also see https://github.com/polkit-org/polkit/pull/562, which adds support for
$SUDO_UID/$SUDO_GID to pkexec.
(cherry picked from commit cd93478af8)
(cherry picked from commit b93f53c122)
$PAGER wasn't documented, but actually we treat it same as $SYSTEMD_PAGER,
except for lower priority. And the two variables can be used to disable the
pager, even if $SYSTEMD_PAGERSECURE is not set.
Behaviour is (obviously) not changed by this patch, it intentionally just
updates the docs to match the code.
(cherry picked from commit b6b78170e1)
(cherry picked from commit affb45d6b2)
The existing description was not *wrong*, but it was a bit muddled. Let's
reorder the text to give a short intro and then describe what the options
actually do and the clear "true" and "false" cases first, and then describe
autodetection.
Related to https://yeswehack.com/vulnerability-center/reports/346802.
(cherry picked from commit 718dbdb2ca)
(cherry picked from commit d8659058f4)
On Linux, read() on a message queue descriptor returns the message
queue statistics, not the actual message queue data. We need to use
mq_receive() to drain the queues instead.
Fixes a problem where a POSIX message queue socket unit with messages
in the queue at shutdown time could result in a hang on reboot/shutdown.
(cherry picked from commit ffb6adb763)
(cherry picked from commit 4ab235b029)
The text is reordered and broken into more paragraphs.
A recommendation to combine RestrictAddressFamilies= with
SystemCallFilter=@service is added.
(cherry picked from commit 2dc4e87849)
(cherry picked from commit 523197c243)
The existing text grew organically as features were added and was
not very organized. Reorder it and break into paragraphs grouped
by topic. The description of the :errno syntax is replaced by a short
reference to the SystemCallErrorNumber= setting. This makes the
text shorter and makes it easier to explain how the two settings combine.
(cherry picked from commit 802d23fcfb)
(cherry picked from commit 0ff20b0486)
Currently, Fedora's systemd RPM doesn't own systemenvgeneratordir
(ie., /usr/lib/systemd/system-environment-generators) [1] because it's
not created when systemd is installed. In contrast, userenvgeneratordir
(ie., /usr/lib/systemd/user-environment-generators) is created, unless
the environment-d Meson option is explicitly disabled.
While this can be worked around elsewhere, it's better if the upstream
build system created the directories consistently. It will avoid
repetition, and prevent silly bugs or deviations from creeping in.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2284085
(cherry picked from commit ab46feb3e2)
(cherry picked from commit bd27edd3de)
Document .link .network and .netdev file type distinctions in early
introductory text, and document distro-specific need to sync link files
with early-boot copies, see Debian bug 1005282:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005282 for an
example.
(cherry picked from commit a50fa2a40f)
(cherry picked from commit 1f654739f8)
fixes:
```
qemu-kvm: -device vmgenid,guid=5f303a47-6fae-4dd7-969c-6c1ea61e816e: 'vmgenid' is not a valid device model name
```
(cherry picked from commit f17247c701)
(cherry picked from commit ddda4deda6)
Otherwise passing invalid data means asserts get hit instead of
handling it gracefully. Other verbs already do the same checks.
busctl get-property org.freedesktop.systemd1 '*' org.freedesktop.systemd1.Manager Version
Assertion 'object_path_is_valid(path)' failed at src/libsystemd/sd-bus/bus-message.c:562, function sd_bus_message_new_method_call(). Aborting.
Aborted (core dumped)
(cherry picked from commit b16e6fd767)
(cherry picked from commit 6961d8ac6e)
A host can send Router Advertisements (RAs) without acting as a router.
In such cases, the lifetime of the RA header should be zero, but may
contain several options, and clients can configure addresses, routes,
and so on with the message. The host may (should?) send Neighbor
Announcements (NAs) without the router flag in that case.
So, when a NA without the router flag is received, let's not drop
configurations based on the previous RA options, but only drop the
default gateway configured based on the RA header.
See RFC 4861 Neighbor Discovery in IPv6, section 6.3.4:
https://www.rfc-editor.org/rfc/rfc4861#section-6.3.4:~:text=%2D%20The%20IsRouter%20flag,as%20a%20host.
> - The IsRouter flag in the cache entry MUST be set based on the Router
> flag in the received advertisement. In those cases where the IsRouter
> flag changes from TRUE to FALSE as a result of this update, the node
> MUST remove that router from the Default Router List and update the
> Destination Cache entries for all destinations using that neighbor as
> a router as specified in Section 7.3.3. This is needed to detect when
> a node that is used as a router stops forwarding packets due to being
> configured as a host.
Fixes a regression caused by 87a33c0740 (v256).
Fixes#37198.
(cherry picked from commit 9142bd5a8e)
(cherry picked from commit a98e9764e3)
Document effect of the SR-IOV section in .link vs .network files and
restructure the SR-IOV section introduction for clarity.
(cherry picked from commit 8e24558e61)
(cherry picked from commit 3a668aae13)
253 is the max number of fds one can send at once on a Linux AF_UNIX
socket. Hence refuse to send more early.
(cherry picked from commit 92c52a9ba6)
(cherry picked from commit d80f2b149c)
The previous commit removed the UINT_MAX check for the fd array. Let's
now re-add one, but at a better place, and with a more useful limit. As
it turns out the kernel does not allow passing more than 253 fds at the
same time, hence use that as limit. And do so immediately before
calculating the control buffer size, so that we catch multiplication
overflows.
(cherry picked from commit cb42df5310)
`clock_nanosleep()` returns error codes directly, rather than using
`errno`. Ensure that we use those codes, rather than checking for `<0`.
(cherry picked from commit 8166075498)
(cherry picked from commit b61ef0b632)
