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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Also fix the grammar: "neither" can only be used with two values, and
here we have an inderminate number >= 1.
Fixes#26460.
(cherry picked from commit 2f76f1cfaee2f775df8b367cb77aed751af45956)
Fixes#26413: the docs said that the filter prevents writes, but it just a
filter at the system call level, and some of those calls are used for writing
and reading. This is confusing esp. when a higher level library call like
ntp_gettime() is denied.
I don't think it's realistic that we'll make the filter smarter in the near
future, so let's change the docs to describe the implementation.
Also, split out the advice part into a separate paragraph.
(cherry picked from commit 42eccfec6e47a5436bd143ee357d2a2da620c2f2)
Otherwise hilarity ensues:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==722==ERROR: AddressSanitizer: SEGV on unknown address 0xffffffff00000000 (pc 0x7f8d50ca9ffb bp 0x7fff11b0d4a0 sp 0x7fff11b0cc30 T0)
==722==The signal is caused by a READ memory access.
#0 0x7f8d50ca9ffb in __interceptor_strcmp.part.0 (/lib64/libasan.so.8+0xa9ffb)
#1 0x7f8d4f9cf5a1 in strcmp_ptr ../src/fundamental/string-util-fundamental.h:33
#2 0x7f8d4f9cf5f8 in streq_ptr ../src/fundamental/string-util-fundamental.h:46
#3 0x7f8d4f9d74d2 in free_and_strdup ../src/basic/string-util.c:948
#4 0x49139a in free_and_strdup_warn ../src/basic/string-util.h:197
#5 0x4923eb in oci_absolute_path ../src/nspawn/nspawn-oci.c:139
#6 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
#7 0x4a8831 in oci_hooks_array ../src/nspawn/nspawn-oci.c:2089
#8 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
#9 0x4a8b56 in oci_hooks ../src/nspawn/nspawn-oci.c:2112
#10 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
#11 0x4aa298 in oci_load ../src/nspawn/nspawn-oci.c:2197
#12 0x446cec in load_oci_bundle ../src/nspawn/nspawn.c:4744
#13 0x44ffa7 in run ../src/nspawn/nspawn.c:5477
#14 0x4552fb in main ../src/nspawn/nspawn.c:5920
#15 0x7f8d4e04a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#16 0x7f8d4e04a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#17 0x40d284 in _start (/usr/bin/systemd-nspawn+0x40d284)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.8+0xa9ffb) in __interceptor_strcmp.part.0
==722==ABORTING
(cherry picked from commit f4e5c042c9a5659a5eebb4c91c0f1132f02a2c59)
Use the returned errno even though we are going to ignore it, otherwise
the log message is just confusing:
config.json:119:13: Failed to resolve device node 4:2, ignoring: Success
(cherry picked from commit e5c275fedc0ab416730fe288a8754a20a014e200)
When merging the settings we take the pointer to the array of extra
devices, but don't reset the array counter to zero. This later leads to
a NULL pointer dereference, where device_node_array_free() attempts to
loop over a NULL pointer:
+ systemd-nspawn --oci-bundle=/var/lib/machines/testsuite-13.oci-bundle.Npo
../src/nspawn/nspawn-settings.c:118:29: runtime error: member access within null pointer of type 'struct DeviceNode'
#0 0x4b91ee in device_node_array_free ../src/nspawn/nspawn-settings.c:118
#1 0x4ba42a in settings_free ../src/nspawn/nspawn-settings.c:161
#2 0x410b79 in settings_freep ../src/nspawn/nspawn-settings.h:249
#3 0x446ce8 in load_oci_bundle ../src/nspawn/nspawn.c:4733
#4 0x44ff42 in run ../src/nspawn/nspawn.c:5476
#5 0x455296 in main ../src/nspawn/nspawn.c:5919
#6 0x7f0cb7a4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#7 0x7f0cb7a4a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#8 0x40d284 in _start (/usr/bin/systemd-nspawn+0x40d284)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/nspawn/nspawn-settings.c:118:29 in
Also, add an appropriate assert to catch such issues in the future.
(cherry picked from commit 825210d4e5d52655ff893d600da2d2c8e5c0c8e1)
Unlike most other bus connections in our codebase this one is created
manually and every setting set invididually. It hence does not have a
description by default (as all automatic connections have). Set one
explicitly.
(cherry picked from commit acf493390ac601d90dc4ac188475635a5c327522)
+ machinectl status long-running long-running long-running
=================================================================
==986==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1568 byte(s) in 2 object(s) allocated from:
#0 0x7fe57caba097 in calloc (/lib64/libasan.so.8+0xba097)
#1 0x7fe57b891e8e in message_from_header ../src/libsystemd/sd-bus/bus-message.c:372
#2 0x7fe57b892dfd in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:421
#3 0x7fe57b9089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
#4 0x7fe57b90affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
#5 0x7fe57b92db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
#6 0x7fe57b933352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
#7 0x7fe57b84da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
#8 0x7fe57b2789e8 in bus_call_method ../src/shared/bus-locator.c:109
#9 0x40f71c in show_machine ../src/machine/machinectl.c:713
#10 0x7fe57b65c8cf in dispatch_verb ../src/shared/verbs.c:103
#11 0x42e9ce in machinectl_main ../src/machine/machinectl.c:2980
#12 0x42ebf9 in run ../src/machine/machinectl.c:3005
#13 0x42ed1f in main ../src/machine/machinectl.c:3008
#14 0x7fe579e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Indirect leak of 234 byte(s) in 2 object(s) allocated from:
#0 0x7fe57cab95b5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xb95b5)
#1 0x7fe57b909822 in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1214
#2 0x7fe57b92db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
#3 0x7fe57b933352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
#4 0x7fe57b84da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
#5 0x7fe57b2789e8 in bus_call_method ../src/shared/bus-locator.c:109
#6 0x40f71c in show_machine ../src/machine/machinectl.c:713
#7 0x7fe57b65c8cf in dispatch_verb ../src/shared/verbs.c:103
#8 0x42e9ce in machinectl_main ../src/machine/machinectl.c:2980
#9 0x42ebf9 in run ../src/machine/machinectl.c:3005
#10 0x42ed1f in main ../src/machine/machinectl.c:3008
#11 0x7fe579e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Indirect leak of 4 byte(s) in 2 object(s) allocated from:
#0 0x7fe57ca7243b in strdup (/lib64/libasan.so.8+0x7243b)
#1 0x7fe57b8c1543 in message_parse_fields ../src/libsystemd/sd-bus/bus-message.c:4125
#2 0x7fe57b893586 in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:443
#3 0x7fe57b9089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
#4 0x7fe57b90affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
#5 0x7fe57b92db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
#6 0x7fe57b933352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
#7 0x7fe57b84da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
#8 0x7fe57b2789e8 in bus_call_method ../src/shared/bus-locator.c:109
#9 0x40f71c in show_machine ../src/machine/machinectl.c:713
#10 0x7fe57b65c8cf in dispatch_verb ../src/shared/verbs.c:103
#11 0x42e9ce in machinectl_main ../src/machine/machinectl.c:2980
#12 0x42ebf9 in run ../src/machine/machinectl.c:3005
#13 0x42ed1f in main ../src/machine/machinectl.c:3008
#14 0x7fe579e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
SUMMARY: AddressSanitizer: 1806 byte(s) leaked in 6 allocation(s).
(cherry picked from commit efdaa92ecb1b358e9f27f7d263bb3383f6ab69c9)
+ machinectl image-status container1 container1 container0 container1 container2 container3 container4
=================================================================
==1354==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4704 byte(s) in 6 object(s) allocated from:
#0 0x7fc3670ba097 in calloc (/lib64/libasan.so.8+0xba097)
#1 0x7fc365e91e8e in message_from_header ../src/libsystemd/sd-bus/bus-message.c:372
#2 0x7fc365e92dfd in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:421
#3 0x7fc365f089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
#4 0x7fc365f0affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
#5 0x7fc365f2db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
#6 0x7fc365f33352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
#7 0x7fc365e4da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
#8 0x7fc3658789e8 in bus_call_method ../src/shared/bus-locator.c:109
#9 0x413b76 in show_image ../src/machine/machinectl.c:1014
#10 0x7fc365c5c8cf in dispatch_verb ../src/shared/verbs.c:103
#11 0x42e992 in machinectl_main ../src/machine/machinectl.c:2981
#12 0x42ebbd in run ../src/machine/machinectl.c:3006
#13 0x42ece3 in main ../src/machine/machinectl.c:3009
#14 0x7fc36444a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Indirect leak of 666 byte(s) in 6 object(s) allocated from:
#0 0x7fc3670b95b5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xb95b5)
#1 0x7fc365f09822 in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1214
#2 0x7fc365f2db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
#3 0x7fc365f33352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
#4 0x7fc365e4da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
#5 0x7fc3658789e8 in bus_call_method ../src/shared/bus-locator.c:109
#6 0x413b76 in show_image ../src/machine/machinectl.c:1014
#7 0x7fc365c5c8cf in dispatch_verb ../src/shared/verbs.c:103
#8 0x42e992 in machinectl_main ../src/machine/machinectl.c:2981
#9 0x42ebbd in run ../src/machine/machinectl.c:3006
#10 0x42ece3 in main ../src/machine/machinectl.c:3009
#11 0x7fc36444a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Indirect leak of 12 byte(s) in 6 object(s) allocated from:
#0 0x7fc36707243b in strdup (/lib64/libasan.so.8+0x7243b)
#1 0x7fc365ec1543 in message_parse_fields ../src/libsystemd/sd-bus/bus-message.c:4125
#2 0x7fc365e93586 in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:443
#3 0x7fc365f089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
#4 0x7fc365f0affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
#5 0x7fc365f2db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
#6 0x7fc365f33352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
#7 0x7fc365e4da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
#8 0x7fc3658789e8 in bus_call_method ../src/shared/bus-locator.c:109
#9 0x413b76 in show_image ../src/machine/machinectl.c:1014
#10 0x7fc365c5c8cf in dispatch_verb ../src/shared/verbs.c:103
#11 0x42e992 in machinectl_main ../src/machine/machinectl.c:2981
#12 0x42ebbd in run ../src/machine/machinectl.c:3006
#13 0x42ece3 in main ../src/machine/machinectl.c:3009
#14 0x7fc36444a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
SUMMARY: AddressSanitizer: 5382 byte(s) leaked in 18 allocation(s).
(cherry picked from commit 4b6ce580eee3f70412637c1df4239e448995535f)
(cherry picked from commit d7aee3f41f69f46d8328f658cab84f8a4b05bb86)
Backport of the cloexec filter for v253, and for v252 (actually tested
with v252). Note that I've left the name _s of the function parameter as
it was before.
So here's the thing. One library we use (libselinux) is opening fds
behind our back when we initialize it and keeps it open. On the other
hand we want to automatically pick up all fds passed in to us, so that
we can distribute them to our services and close the rest. We pick them
up very early in our code, to ensure that we don't get confused by open
fds at that point. Except that libselinux insists on being initialized
even earlier. So suddenly we might take possession of libselinux' fds,
and then close them later when we decide no service wants them. Then
during shutdown we close down selinux and selinux closes its fds, but
since already closed long ago this ight close our fds instead. Hilarity
ensues.
I wish low-level software wouldn't do such things behind our back, but
well, let's make the best of it.
This changes the fd pick-up logic to only pick up fds that have
O_CLOEXEC unset. O_CLOEXEC must be unset for any fds passed in to us
over execve() after all. And for all our own fds we should set O_CLOEXEC
since we generally don't want to litter fd tables for execve(). Also,
libselinux thankfully appears to set O_CLOEXEC correctly on its fds,
hence the filter works.
Fixes: #27491
(cherry picked from commit eb564f928e401def8d3aaa2a90f33cb09cdc1517)
Backport of the cloexec filter for v253, and for v252 (actually tested
with v252). Note that I've left the name _s of the function parameter as
it was before.
The systemd-cryptenroll man page states:
Takes a comma separated list of numeric slot indexes, or the special
strings ..., or any combination of these strings or numeric
indexes, in which case all slots matching either are wiped.
but we'd allow only one special string at any given time as the value
was not ORed when assigning. So, for example, --wipe=recovery,password
would actually become --wipe=password, etc.
(cherry picked from commit b0582f6b635011506fdf68d0afdc128ab10f6c6a)
Then, if it is invalid, refuse to use the entry array object.
Follow-up for a8fbcc0e3c033a43e511550052cace6b0dcf3df7.
Fixes#27489.
(cherry picked from commit b5335da7a54d6597a1539b56b5a0cb1f8d36dfdd)
>=musl-1.2.4 doesn't define dirent64 and its LFS friends as its "native"
functions are already LFS-aware.
Check for dirent64 in meson.build and only assert if it exists.
Bug: https://bugs.gentoo.org/905900
Closes: https://github.com/systemd/systemd/pull/25809
(cherry picked from commit eb29296937b268e0140a2ab1cf204c2ebb72fa5a)
GCC document [1] says:
The pure attribute prohibits a function from modifying the state
of the program that is observable by means other than inspecting
the function’s return value.
And there is an example:
`int hash (char *) __attribute__ ((pure));`
... Even though hash takes a non-const pointer argument it must
not modify the array it points to, ...
But we are modifying the object pointed to by the pointer u, which is
clearly a violation of the semantic of pure.
With -ftrivial-auto-var-init (enabled by -Dmode=release), on some
targets (GCC 12.2 on AArch64 and GCC 13.1 on x86_64) performs an
optimization: as the variable "u" in bus_match_parse has been
zero-initialized (by the -ftrivial-auto-var-init option) and never
modified (because a "pure" bus_message_type_from_string is not allowed
to modify it), "u" will be always 0.
Then 0 is used to initialize .value_u8 field of struct
bus_match_component. This then causes a infinite event loop, so
"systemctl restart" never stops, and pam_systemd timeouts communicating
with logind, etc.
So we should remove the "pure" attribute here.
Fixes#26395.
[1]:https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-pure-function-attribute
(cherry picked from commit 6723c28f36ea566faf61d3610012cd89f95ee4a0)
Passing 0 to log_xxx_errno() leads to an assertion, so let's not do that:
$ NEWPASSWORD="" build-san/systemd-cryptenroll --unlock-key-file=/tmp/password --password "$img"
/tmp/password has 0644 mode that is too permissive, please adjust the ownership and access mode.
Assertion '(_error) != 0' failed at src/cryptenroll/cryptenroll-password.c:164, function enroll_password(). Aborting.
Aborted (core dumped)
(cherry picked from commit 0e43ab6d245a77aab35c7963ec636f37e6103984)
It was added to CAP_NET_ADMIN but we forgot to add it to the template
service as well.
(cherry picked from commit 97211510b06b01a4f053d4cacba4ad4184849bcf)
Since we do `FD_TO_PTR(fd)` that expands to `INT_TO_PTR(fd) + 1` which
triggers an integer overflow.
Resolves: #27522
(cherry picked from commit cc938f1ce0f1eafc435e0dd1d9fe45aaedc526e1)
The usage of PREFIX in this completion is mostly counter to the intended
usage of compsys in zsh. It is generally expected that completion code
provide the available completions and tags in that word position so that
compsys, with user configuration, can filter them to the appropriate set.
One egregious error caused by the usage of PREFIX here is the caching of
SYS_ALL_UNITS, which stored only the unit names prematurely filtered by
the completion prefix, affecting all future completions. For example,
$ systemctl cat nonsense<TAB>
might find no matching units if nonsense* has no matches, but now
$ systemctl cat <TAB>
will fail in all future completions even though every unit file
is a valid match, because the cached set has been erroneously filtered
by the last prefix.
(cherry picked from commit 8139407ec109594c11c8c7d2936e9f0eba610f05)
If a container manager does not follow the guidance in
https://systemd.io/CONTAINER_INTERFACE/ regarding audit capabilities,
then the current check may not be sufficient to determine that audit
will function properly. In particular, when calling bind() on the audit
fd, we will get EPERM if running in a user-namespaced container.
Expand the check to make an AUDIT_GET_FEATURE request on the audit fd to
test if it is working. If this fails with ECONNREFUSED, we know it is
because the kernel does not support the use of audit outside of the
initial user namespace.
Note that the approach of this patch was suggested here:
https://github.com/systemd/systemd/pull/19443#issuecomment-829566659Fixes: #6519
(cherry picked from commit 362235bf59f8ddc6d67be3d6c8604f7fd05d383d)
We were using the wrong memory type when allocating pool memory. This
does not seem to cause a problem on x86, but the kernel will fail to
boot at least on ARM in QEMU.
This is caused by mixing different allocation types which ended up
breaking the kernel or EDK2 during boot services exit. Commit
2f3c3b0bee5534f2338439f04b0aa517479f8b76 appears to fix this boot
failure because it was replacing the gnu-efi xpool_print with xasprintf
thereby unifying the allocation type.
But this same issue can also happen without this fix somehow when the
random-seed logic is in use.
Fixes: #27371
(cherry picked from commit ec232e4abd7aebfec06b4814b30129532b2bcefd)
This ensures that systemd won't erronously disconnect from the system
bus in case a bus recheck is triggered immediately after the bus service
emits `RELOADING=1`.
This fixes an issue where systemd-logind sometimes randomly stops
receiving `UnitRemoved` after a system update.
This also handles SERVICE_RELOAD_SIGNAL just in case somebody ever
creates a D-Bus broker implementation that uses `Type=notify-reload`.
(cherry picked from commit 845824acddf2e7e08c94afe7cfee6e50a682c947)
When spawning generators within a sandbox we want a private /tmp, but it
might not exist, and on some systems we might be unable to create it
because users want a BTRFS subvolume instead.
Fixes https://github.com/systemd/systemd/issues/27436
(cherry picked from commit b8fba0cded2c3e14fe8c0b52aae3ecf2c9fa718e)
If the test environment is too slow, then sleeping 2 seconds may not be
sufficient.
(cherry picked from commit e94756c5668697d0b11f4cdf449a2fbfe13ffb1f)
