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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If - for whatever reason - a script uses set -u (nounset) and includes
/etc/profile.d/70-systemd-shell-extra.sh (e.g. transitively via
/etc/profile) the script would fail with:
/etc/profile.d/70-systemd-shell-extra.sh: line 15: SHELL_PROMPT_PREFIX: unbound variable
For example:
$ cat > foo.sh <<EOF
#!/bin/sh
set -u
source /etc/profile
EOF
$ chmod 700 foo.sh
$ ./foo.sh
/etc/profile.d/70-systemd-shell-extra.sh: line 15: SHELL_PROMPT_PREFIX: unbound variable
Fix this by using shell parameter substitution[^1] (which is a POSIX
shell concept) to set the $SHELL_* variables to the empty string if
undefined.
[^1]: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/V3_chap02.html
(cherry picked from commit 12e33d332b)
Document the fact that read-only properties may not have the flag
SD_BUS_VTABLE_UNPRIVILEGED as that is not obvious especially given the
flag is accepted for writable properties.
Based on the check in `add_object_vtable_internal` called by
`sd_bus_add_object_vtable` (as of the current tip of the main branch
f7f5ba0192):
case _SD_BUS_VTABLE_PROPERTY: {
[...]
if ([...] ||
[...]
(v->flags & SD_BUS_VTABLE_UNPRIVILEGED && v->type == _SD_BUS_VTABLE_PROPERTY)) {
r = -EINVAL;
goto fail;
}
(where `_SD_BUS_VTABLE_PROPERTY` means read-only property whereas
`_SD_BUS_VTABLE_WRITABLE_PROPERTY` maps to writable property).
This was implemented in the commit
adacb9575a ("bus: introduce "trusted" bus
concept and encode access control in object vtables") where
`SD_BUS_VTABLE_UNPRIVILEGED` was introduced:
Writable properties are also subject to SD_BUS_VTABLE_UNPRIVILEGED
and SD_BUS_VTABLE_CAPABILITY() for controlling write access to them.
Note however that read access is unrestricted, as PropertiesChanged
messages might send out the values anyway as an unrestricted
broadcast.
(cherry picked from commit 3ca09aa4dd)
/dev/null is a character device, so same_fd() in the fallback path
that compares fstat will fail, as that bails out if the fd refers
to a char device. This happens on kernels without F_DUPFD_QUERY and
without kcmp.
/* test_same_fd */
Assertion 'same_fd(d, e) > 0' failed at src/test/test-fd-util.c:111, function test_same_fd(). Aborting.
Fixes#35552
(cherry picked from commit 3b32d333e8)
To reproduce, as an unprivileged user start a docker container and build
and run the unit tests inside it:
$ docker run --rm -ti debian:bookworm bash
...
/* test_close_all_fds */
Successfully forked off '(caf-plain)' as PID 10496.
Skipping PR_SET_MM, as we don't have privileges.
(caf-plain) succeeded.
Failed to fork off '(caf-noproc)': Operation not permitted
Assertion 'r >= 0' failed at src/test/test-fd-util.c:392, function test_close_all_fds(). Aborting.
Partially fixes#35552
(cherry picked from commit 630a2e7ee1)
have ambient caps: yes
Capabilities:cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
Failed to drop auxiliary groups list: Operation not permitted
Failed to change group ID: Operation not permitted
Capabilities:cap_dac_override,cap_net_raw=ep
Capabilities:cap_dac_override=ep
Successfully forked off '(getambient)' as PID 12505.
Skipping PR_SET_MM, as we don't have privileges.
Ambient capability cap_linux_immutable requested but missing from bounding set, suppressing automatically.
Assertion 'x < 0 || FLAGS_SET(c, UINT64_C(1) << CAP_LINUX_IMMUTABLE)' failed at src/test/test-capability.c:273, function test_capability_get_ambient(). Aborting.
(getambient) terminated by signal ABRT.
src/test/test-capability.c:258: Assertion failed: expected "r" to succeed, but got error: Protocol error
Partially fixes#35552
(cherry picked from commit 058a07635f)
TEST-75-RESOLVED fails on Ubuntu autopkgtest due to this warning from
knot:
notice: config, policy 'auto_rollover_nsec3' depends on default nsec3-salt-length=8, since version 3.5 the default becomes 0
Explicitly set nsec3-salt-length=8 to silence.
(cherry picked from commit 59e5108fb4)
These new tests are flaky, so disable them temporarily, until after
the release, to avoid pushing out new flakiness to consumers. They
will be re-enabled immediately after.
Instead of the wrapper functions the color defines where used directly.
This was especially a problem for ANSI_HIGHLIGHT_YELLOW which is not
legible at all for light themes such as solarized. The 16 color palette
fallback can be set to a sane yellow or orange on that matter but it was
not used though `SYSTEMD_COLORS=16` was set.
Use the proper wrapper functions and let the right color be selected the
way other components do it already.
We'd silently skip devices which don't have the feature in the list.
This looked wrong esp. if no devices were suitable. Instead, list them
and show which ones are usable.
$ build/systemd-cryptenroll --fido2-device=list
PATH MANUFACTURER PRODUCT HMAC SECRET
/dev/hidraw7 Yubico YubiKey OTP+FIDO+CCID ✓
/dev/hidraw10 Yubico Security Key by Yubico ✗
/dev/hidraw5 Yubico Security Key by Yubico ✗
/dev/hidraw9 Yubico Yubikey 4 OTP+U2F+CCID ✗
The values that were previously hardcoded in sd-varlink.c are now defined
in new varlink_set_info_systemd() and that function is called everywhere
where we create a server.
Fixes https://github.com/systemd/systemd/issues/35508.
As reported in the bug, the values were hardcoded for the systemd project.
https://varlink.org/Service lists vendor, product, version, url, and interfaces
as the mandatory parameters, so add an interface to set the first four. The
last field is set automatically based on the registered interfaces as before.
If the values are not filled in, we return empty strings. With NULL,
'varlinkctl info' would say:
(string):1:25: Object field 'vendor' has wrong type null, expected string.
Otherwise, if networkd is failed, e.g. .network files that triggered the
failure will remain, and the next test case will start with previous
.network files. So, most subsequent test will fail.
This adds the following three options:
- detect_invalid_pointer_pairs=2
- handle_ioctl=1
- print_cmdline=1
Note, these options were used in the CentOS CI job.
To build rawhide images we might need more recent tools from rawhide
itself. While Arch would generally be up-to-date enough as well, it
doesn't provide the selinux tools so we use Fedora Rawhide instead.
This is a revised version of cbd5f5d7d6,
which is reverted by 560412148f.
The filter condition for _UID= field was added by
fdcd37df3b. However, after
888e378da2, coredumps for system services are
stored by systemd-coredump user. Hence, _UID=0 does not match anything anymore.
When we are reading the system journal, let's set _UID=<systemd-coredump>,
then we can show coredumps for system services again. When we are reading
an external journal, then the uid of systemd-coredump may be different
from the one on the current system, so let's drop the filter condition
for _UID= in that case.
This is a follow-up for f8fa4222c9 (boot: Make
initrd_prepare() semantically equivalent to combine_initrds()). That commit
changed the way that the initrd is prepared for type#1 boot loader entries,
also effectively rounding up the sizes to a multiple of 4. In [1], downstream
packagers report that the trailing zeroes result in the calculated hash being
different. To restore compatibility with previous hash calculations and
signatures, change the reported size by excluding the trailing padding. This
should restore the calculation results for the case where only one initrd is
used.
This patch doesn't touch the stub, i.e. doesn't change behaviour for UKIs. The
seems fine, since we didn't change that recently, so any changes there would
break compatiblity. The measurement results for type#1 and type#2 entries are
generally going to be different anyway. ukify and systemd-measure are also out
of scope here, because they are for UKIs.
Fixes https://github.com/systemd/systemd/issues/35439.
The other changes to the way the initrd is constructed are kept, so hopefully
the original issue with booting in qemu is not recreated.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1233752
My simple test: I'm booting a QEMU VM with systemd-boot and a type#1 entry.
With old systemd-boot:
$ sudo systemd-pcrlock log | grep 'kernel-initrd.*event-tag'
9 █ kernel-initrd event-tag - a337a8321bf81de5c53a842843e8f9a926f73a676e5620ff76df94d1c66bc931 F - Linux: kernel command line
9 █ kernel-initrd event-tag - aec1aee5358bde36f5498f2dc243dec2b103f81242de57b887a11f53677f1272 F - Linux: initrd
With updated systemd-boot:
$ sudo systemd-pcrlock log | grep 'kernel-initrd.*event-tag'
9 █ kernel-initrd event-tag - a337a8321bf81de5c53a842843e8f9a926f73a676e5620ff76df94d1c66bc931 F - Linux: kernel command line
9 █ kernel-initrd event-tag - 3ccaa710304aef8734a20265ea7fd3dd67d5461c6b3309c6d30d5c7d2a3ae7f9 F - Linux: initrd
This matches the initrd hash:
$ sudo sha256sum /efi//26f948d2082e4ae89f5a3af351b63149/6.12.0-rc4+/initrd-dracut
3ccaa710304aef8734a20265ea7fd3dd67d5461c6b3309c6d30d5c7d2a3ae7f9 /efi//26f948d2082e4ae89f5a3af351b63149/6.12.0-rc4+/initrd-dracut
