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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Prompted by #27595.
Follow-ups for 6723c28f36ea566faf61d3610012cd89f95ee4a0.
(cherry picked from commit bc52801034e9e33d7aab0cb64c84f64cd9d4c035)
(cherry picked from commit 0baac8e60ef1d26fa0a356f1b7d6a1ed3cd207e0)
>=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)
(cherry picked from commit 4984f70db5b1ce3103dfb6b2ecdbced86bf92703)
Follow-up for c03ef420fa7157b8d4881636fe72596a06e08bb6
(cherry picked from commit 8707dcdf3b5b4b01530639389350505fcb700969)
(cherry picked from commit 5fcbda8b5ec488955d911aca00545d2b80d9ec47)
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)
(cherry picked from commit 59dccdfddbdde5d4ff047108a545106f2bac6872)
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)
(cherry picked from commit 133d4ff6d69594e60a546d1efbbd29bc5bfc4f31)
It was added to CAP_NET_ADMIN but we forgot to add it to the template
service as well.
(cherry picked from commit 97211510b06b01a4f053d4cacba4ad4184849bcf)
(cherry picked from commit c937b8f9ded035ef5730ef9db7bf0beb9eafed1b)
Fixes a bug caused by a5648b809457d120500b2acb18b31e2168a4817a.
Fixes#27575.
(cherry picked from commit f86a388de339bc9fd3bc90df7de0d9693b52369f)
(cherry picked from commit 53f7e5f18f19612c4514fce367d7504a9ad8e710)
DefaultControlGroup does not exist any more.
(cherry picked from commit 4fad639a1350b1ce2fa77249f8e81dcc4229ee57)
(cherry picked from commit 32831842bade4d91ff00cf2bbbb12008dd55f835)
Follow-up for 7bd3d6e35a6de8b1bf93e2fae28a64f0c7ffd2ac.
Fixes#27516.
(cherry picked from commit 5b5e54e058745f47184cb88e0037fa576164000c)
(cherry picked from commit 927d2344061b0b74200c54ea38b4daabf2a34273)
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)
(cherry picked from commit 154b108513fe4aa50e7f347abeb0f0d9789a32df)
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)
(cherry picked from commit a25605d01d9383070e7b207e64588c83c61241bd)
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)
(cherry picked from commit 4be604e75a38cb0ddbde3f2ade6ae65664fe77be)
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)
(cherry picked from commit 6ae77d6b99dce05ffb2b9bad3de1c3cafa1d45a8)
If the test environment is too slow, then sleeping 2 seconds may not be
sufficient.
(cherry picked from commit e94756c5668697d0b11f4cdf449a2fbfe13ffb1f)
(cherry picked from commit 93143b6d6ae42594b5934d2594081e9396310ee0)
When multi-word matching string is quoted, __contains_word compares
it as a whole to the passed option, so it doesn't work.
(cherry picked from commit 20ed583e35cd30ad06c14a0ba833e71c4ca69b48)
(cherry picked from commit dd349a0ede057829f1970260f81ace2fedb6d8d6)
Otherwise,
1. X.path triggered X.service, and the service has waiting start job,
2. systemctl stop X.service
3. the waiting start job is cancelled to install new stop job,
4. path_trigger_notify() is called, and may reinstall new start job,
5. the stop job cannot be installed, and triggeres assertion.
So, instead, let's add a defer event source, then enqueue the new start
job after the stop (or any other type) job finished.
Fixes https://github.com/systemd/systemd/issues/24577#issuecomment-1522628906.
(cherry picked from commit bc6377762c210d1bdd7fd2465930731d87dda576)
(cherry picked from commit 03f2a8921ee0671710f920896c0234b9793c07c5)
When we fail to deserialize job ID, or the current_job_id is overflowed,
we may have jobs with the same ID.
This is paranoia, and just for safety.
Note, we already use hashmap_remove_value() in job_uninstall().
(cherry picked from commit c49dfd8911f49bf383ad7ac1d18be8a4ab39ab09)
(cherry picked from commit 53ac14a05456c787cf62cb864b2036634c40f617)
The pointer to boot ID may be invalidate by journal_file_move_to_object()
calls in the later loop.
(cherry picked from commit bf9b7728e6e8eb185d2c9bfc6641077489384bc8)
(cherry picked from commit 3bc2553cfcc57144aadacff0555b1a0e45e3fdbf)
If journal_file_data_payload() returns -EBADMSG or -EADDRNOTAVAIL,
we skip the entry and go to the next entry, but we never modify
the number of items that we pass to journal_file_append_entry_internal()
if that happens, which means we could try to append garbage to the
journal file.
Let's keep track of the number of fields we've appended to avoid this
problem.
(cherry picked from commit f81409f844ae8077f7ee7664871f73fa7d440581)
(cherry picked from commit 3821e3ea077810a7271dbdaccf67b08c33a28fcf)
Since da6053d0a7c16795e7fac1f9ba6694863918a597 this is a size_t, not an
unsigned. The difference doesn't matter on LE archs, but it matters on
BE (i.e. s390x), since we'll return entirely nonsensical data.
Let's fix that.
Follow-up-for: da6053d0a7c16795e7fac1f9ba6694863918a597
An embarassing bug introduced in 2018... That made me scratch my head
for way too long, as it made #27135 fail on s390x while it passed
everywhere else.
(cherry picked from commit 47226e893b24f1aa84caaa6be266fb3c03442904)
(cherry picked from commit a25e2ef992fe14e2340c992e05148b19719480ce)
It no longer works, requires a new version of mkosi that we cannot
pull in the stable branch
(cherry picked from commit 9d97c8d423cff83a61950c3508857a395cb113e3)
systemd-repart needs to find mkfs.ext4 for the test.
This is located in the directory /usr/sbin on openSUSE Tumbleweed.
But since the variable ALWAYS_SET_PATH in /etc/login.defs is set to yes,
su re-initializes the $PATH variable and removes /usr/sbin.
Hence, mkfs.ext4 is not found and the test fails.
Using setpriv instead of su fixes this issue and is more appropriate to
do the switch user task from root.
[zjs: move setpriv to $BASICTOOLS and force-push to retrigger CI]
(cherry picked from commit c7bf1959d7580e1b7e918b75f852b3bf3fb6eb3c)
(cherry picked from commit 43d194392fd36151c339fa7a1a9eebe30490bddb)
Let's attempt to reduce the amount of flakes further when the AWS region
we run in is under heavy load and the hypervisor stars stealing our CPU
time.
Follow-up to e0cbb73911 and c78d18215b.
(cherry picked from commit 72f6d0e556d29b695369493a909562ff1325f8cd)
(cherry picked from commit fdcd1807fff02d4ab7f0d80558f5505ac94f301c)
The kernel returns ERANGE when UINT64_MAX is passed. Create a mask
and use UINT32_max, which is accepted, so that future bits will also
be set.
(cherry picked from commit 7f3bb8f20dcccaceea8b1ee05f0560b81162037b)
(cherry picked from commit 4f8b2abf699f092576efff55a061efede795d99e)
We translate 'all' to UNIT64_MAX, which has a lot more 'f's. Use the
helper macro, since a decimal uint64_t will always be >> than a hex
representation.
root@image:~# systemd-run -t --property CoredumpFilter=all ls /tmp
Running as unit: run-u13.service
Press ^] three times within 1s to disconnect TTY.
*** stack smashing detected ***: terminated
[137256.320511] systemd[1]: run-u13.service: Main process exited, code=dumped, status=6/ABRT
[137256.320850] systemd[1]: run-u13.service: Failed with result 'core-dump'.
(cherry picked from commit 37232d55a7bcace37280e28b207c85f5ca9b3f6b)
(cherry picked from commit 021bb972ffd87aae9f9f7bcc691bf5b812db309b)
