IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* sd-bus/man: document EBUSY error in bus_message_read
The EBUSY error can be returned from sd_bus_exit_container(), and, if
that happens, it will be propogated upwards towards bus_message_read. In
terms of documentation, this means that bus_message_read's man page
can't just include the error text for sd_bus_message_read_basic, as
reading basic types exclusively doesn't have the potential for this
error.
sd_bus_message_read_basic's error documentation isn't incorrect when
applied to sd_bus_message_read, it's just incomplete. While EBUSY is
documented in sd_bus_message_open_container.xml,
it's explanation is unique to the sd_bus_message_exit_container function
and makes for poor documentation of the general read API.
(cherry picked from commit a1a03fa54bfb45315eefaa49ceb38a21aceafde8)
Since bpf_can_link_lsm_program return value is boolean, the expression
`r < 0` is always false.
(cherry picked from commit ccfc534deed2f3873c967851497af10d8a1ee01c)
BPF_RAW_TRACEPOINT_OPEN is expected to work only on x86 and x86_64,
since BPF trampoline is implemented only on these architectures.
Attach probing by bpf_program__attach_lsm already happens in
`bpf_lsm_supported`. The resulting pointer can store libbpf error and
that is the case for unsupported architectures.
Add libbpf error check to `bpf_lsm_supported` so execution does not
reach the point where unit startup fails.
(cherry picked from commit f409aa5c6363144c9711226319614f3b248d9828)
To remove directory structures, we need to remove the innermost items first,
and then recursively remove higher-level directories. We would recursively
descend into directories and invoke rm_rf_children and rm_rm_children_inner.
This is problematic when too many directories are nested.
Instead, let's create a "TODO" queue. In the the queue, for each level we
hold the DIR* object we were working on, and the name of the directory. This
allows us to leave a partially-processed directory, and restart the removal
loop one level down. When done with the inner directory, we use the name to
unlinkat() it from the parent, and proceed with the removal of other items.
Because the nesting is increased by one level, it is best to view this patch
with -b/--ignore-space-change.
This fixes CVE-2021-3997, https://bugzilla.redhat.com/show_bug.cgi?id=2024639.
The issue was reported and patches reviewed by Qualys Team.
Mauro Matteo Cascella and Riccardo Schirone from Red Hat handled the disclosure.
(cherry picked from commit 5b1cf7a9be37e20133c0208005274ce4a5b5c6a1)
Units would fail to start, incl. systemd-journald.service and systemd-udevd.service.
Since unit->manager->restrict_fs will be set if and only if we can use it,
we can just check for that and remove the other checks.
Follow-up for 299d9417238e0727a48ebaabb5a9de0c908ec5c8.
(cherry picked from commit 46004616a12dcdaf11020b8d58f956a006c9d9cf)
Dangling symlinks get pruned when packaging up the installation
directory. Just store empty files instead, and compare the names
rather than the content for .requires/.wants - the filename is
what is important anyway, the content is ignored.
Fixes#22059
(cherry picked from commit e683878c0f03a4ffa123e37b27933fbf7e144901)
It was reported as used by the linker:
> [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start.
> My local call stack (with LTO):
>
> #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2)
> #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2)
> #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2)
> #3 _start (/usr/lib64/ld-linux-x86-64.so.2)
>
> Looking through the source, I think it's this (links for glibc 2.34):
> - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features.
> - Then init_cpu_features calls get_cet_status.
> - At last, get_cet_status invokes arch_prctl.
Fixes#22033.
(cherry picked from commit 5f02870a74aa3a758115cc9bd6d68f239caf8453)
This restores the preference order from before 9e82a74. The code
previous to that change 'preferred' /boot over /boot/efi; that
commit changed it to check /boot/efi before checking /boot.
Changing this precedence could (and did, for me) have unexpected
effects - it seems safer to leave it how it was.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
(cherry picked from commit a5307e173bf86d695fe85b8e15e91126e8618a14)
Otherwise, systemd-homed-active.service will fail to deactivate all
homes because homectl can no longer talk to homed if dbus stops first.
As a result, /home cannot be umounted.
Doing this on systemd-homed-active.service instead works as well, but
systemd-homed will exit 1 if dbus is already shut down.
(cherry picked from commit e00a25a7b41bd45ab73b47cbd94b3af909b8f8a1)
BPF LSM is cgroup unaware and it's set up is happening in core manager.
It occures that the current implementation is too restrictive and causes
pid 1 to freeze.
Instead:
* in bpf_lsm_setup set manager->restrict_fs pointer last,
so it is an indicator that the set up was successful
* check for manager->restrict_fs before applying unit options
(cherry picked from commit 299d9417238e0727a48ebaabb5a9de0c908ec5c8)
The code was written unidiomatically, using r as a boolean value, and
confusing errno and r in some places. AFAICS, there wasn't any actual
problem: even in the one place where errno was used instead of r, it would
almost certainly be initialized.
It seems that some libbpf functions set errno, while others return the
error, possibly encoded. Since there are almost no docs, the only way to
know is to read the code of the function. To make matters worse, there is
a global libbpf_mode which can be set to change the convention. With
LIBBPF_STRICT_DIRECT_ERRS in libbpf_mode, some functions set errno while others
return a negative error, and the only way to know is to read the code, except
that the split is now different. We currently don't set
LIBBPF_STRICT_DIRECT_ERRS, but even the possibility makes everything harder
to grok.
This is all very error-prone. Let's at least add some asserts to make sure that
the returned values are as expected.
(cherry picked from commit b7cba81553d0d958f23182ba9ab1739842ff9f5a)
If something goes wrong with this test it may result in an unsafe
system restart. Let's avoid running it automatically.
See https://github.com/systemd/systemd/issues/22001.
(cherry picked from commit 70652c2a6fa9c06c7faac62f41c72e2e4eaa9340)
If the action failed, we should log about the issue, and continue.
Exiting would bring the graphical session down, which of course is not
appreciated by users.
As documented in previous commits, a non-negative return from the callback
doesn't matter, so the callback is simplified a bit.
Fixes#21991.
(cherry picked from commit 8207b8321bbbcbd19a345deb77d455d98e6ffb84)
Otherwise we might hit a window where the coredump happens before
midnight, but we check for it after midnight, which yields no results.
E.g.:
```
$ coredumpctl --no-legend --no-pager --file system.journal
Wed 2022-01-05 01:00:06 CET 359 0 0 SIGABRT journal /usr/bin/udevadm n/a
$ coredumpctl --since 23:59:55 --no-legend --no-pager --file system.journal
No coredumps found.
$ coredumpctl --since "2022-01-04 23:59:59" --no-legend --no-pager --file system.journal
Wed 2022-01-05 01:00:06 CET 359 0 0 SIGABRT journal /usr/bin/udevadm n/a
```
(cherry picked from commit 1b51599f29d245f2214349498bf2c1f0aa36873f)
The previous message was confusing errors. When we're rotating because
we've reached the file size limit, let's log a better message.
Fixes#22007.
(cherry picked from commit eff79e4e22e7c745fea259c4414f685363d9f16a)
This fixes a bug introduced by 0c674ce5f24a6e52561ec6520e43a1ca45d90f01.
Fixes#22004.
(cherry picked from commit e37d30f334830fab4decd52ef3c17fa09b7b0d92)
The check was added in 77547d5313ea916d2fb64ca5a8812734e9b50f92, but
it doesn't work as expected. Because the second part is wrapped in Optional(),
it would silently "succeed" when the lowercase digits were in the second part:
>>> from parse_hwdb import *
>>> g = 'v' + upperhex_word(4) + Optional('p' + upperhex_word(4))
>>> g.parseString('v04D8pE11C*')
(['v', '04D8', 'p', 'E11C'], {})
>>> g.parseString('v04D8pe11c*')
(['v', '04D8'], {})
The following matches are OK:
usb:v0627p0001:*QEMU USB Keyboard*
usb:v0627p0001:*
usb:v0627p0001*
usb:v0627*
(cherry picked from commit 1a37237e2ffe6dfe142224a9d9e8b24135e93244)
The code assume that meson's cpu_family can be mapped directly to
'-D__<cpu_family>__'. This works in a surprising number of cases, but not for a
few architectures. PPC uses "powerpc", and RISC-V omits the trailing underscores.
ARM and RISC-V require a second define too.
Fixes#21900.
(I don't think this matters too much: we need *something* so that gnu/stubs.h
can be successfully included. But we don't actually call syscalls or depend too
much on the host environment, so things should be fine as long as we don't get
a compilation error.)
(cherry picked from commit e897b07f97cf25e092a4cc8e1144e06564b45d53)
When the support for "synthetic errno" was added, we started truncating
the errno value to just the least significant byte. This is generally OK,
because errno values are defined up to ~130.
The docs don't really say what the maximum value is. But at least in principle
higher values could be added in the future. So let's stop truncating
the values needlessly.
The kernel (or libbpf?) have an error where they return 524 as an errno
value (https://bugzilla.redhat.com/show_bug.cgi?id=2036145). We would
confusingly truncate this to 12 (ENOMEM). It seems much nicer to let
strerror() give us "Unknown error 524" rather than to print the bogus
message about ENOMEM.
(cherry picked from commit 5f74fcd41cb1a1b26c23e0f2ab405ae9cf6bcc93)
The COREDUMP_EXE attribute is "optional", i.e. we continue to process the
crash even if we didn't acquire it. The coredump generation code assumed
that it is always available:
#5 endswith at ../src/fundamental/string-util-fundamental.c:41
[ endswith() is called with NULL here, and an assertion fails. ]
#6 submit_coredump at ../src/coredump/coredump.c:823
#7 process_socket at ../src/coredump/coredump.c:1038
#8 run at ../src/coredump/coredump.c:1413
We use the exe path for loop detection, and also (ultimately) pass it to
dwfl_core_file_report(). The latter seems to be fine will NULL, so let's just
change our code to look at COMM, which should be more reliable anyway.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2036517.
(cherry picked from commit c790632cabf5691b0910fc6b7a5c6af31a7786aa)
The flag is now only used in test-sysctl-util.c, and it should be
replaced with uname(), because of the same reason as the previous
commit.
(cherry picked from commit 9383fa08bd263277d9a17a8999c3497458f273e3)
Previously, sethostname_idempotent_full() calls gethostname_full() with
GET_HOSTNAME_ALLOW_NONE and GET_HOSTNAME_ALLOW_LOCALHOST flags. That
intended to get any values set by kernel. But, that does not work, as
the hostname may be empty.
Let's simplify the logic. The function sethostname_idempotent_full()
intends to set the requested hostname only when the current hostname
is different from the requested one. So, no check in getostname_full()
is required. Hence, simply use the result of uname() here.
Fixes#21896.
(cherry picked from commit d8d6b2275f7b7a5b58c6b0d89b78c927333c6af9)
