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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This adds a high level test verifying that syscall filtering in
combination with a simple architecture filter for the "native"
architecture works fine.
The commit 6597686865 ("seccomp: don't install filters for archs that
can't use syscalls") introduced a regression where filters may not be
installed for the "native" architecture. This means that setting
SystemCallArchitectures=native for a unit effectively disables the
SystemCallFilter= and SystemCallLog= options.
Conceptually, we have two filter stages:
1. architecture used for syscall (SystemCallArchitectures=)
2. syscall + architecture combination (SystemCallFilter=)
The above commit tried to optimize the filter generation by skipping the
second level filtering when it is not required.
However, systemd will never fully block the "native" architecture using
the first level filter. This makes the code a lot simpler, as systemd
can execve() the target binary using its own architecture. And, it
should be perfectly fine as the "native" architecture will always be the
one with the most restrictive seccomp filtering.
Said differently, the bug arises because (on x86_64):
1. x86_64 is permitted by libseccomp already
2. native != x86_64
3. the loop wants to block x86_64 because the permitted set only
contains "native" (i.e. "native" != "x86_64")
4. x86_64 is marked as blocked in seccomp_local_archs
Thereby we have an inconsistency, where it is marked as blocked in the
seccomp_local_archs array but it is allowed by libseccomp. i.e. we will
skip generating filter stage 2 without having stage 1 in place.
The fix is simple, we just skip the native architecture when looping
seccomp_local_archs. This way the inconsistency cannot happen.
systemd-udevd.service listens to kernel uevents and is needed for device
units to be available.
systemd-udevd.service is misspelled as systemd-udev.service in a couple places.
Fixing typo.
Kernels >= 5.8 have added new fields to the dmi/id/modalias file in the
middle of the modalias (instead of adding them at the end).
Specifically new ":br<value>:" and (optional) ":efr<value>:" fields have
been added between the ":bd<value>:" and ":svn<value>:" fields.
Note the 5.13.0 and 5.14.0 kernels also added a new ":sku<value>:" field
between the ":pvr<value>:" and ":rvn<value>:" fields, this has been fixed
in later 5.13.y and 5.14.y releases, by moving the sku field to the end:
https://lore.kernel.org/lkml/20210831130508.14511-1-hdegoede@redhat.com/
Unfortunately the same cannot be done for the new br and efr fields since
those have been added more then a year ago and hwdb even already has some
newer entries relying on the new br field being there (and thus not working
with older kernels).
Fix the issue with the br and efr fields through the following changes:
1. Replace any matches on ":br<value>" from newer entries with an '*'
2. Replace "bd<value>:svn<value>" matches with: "bd<value>:*svn<value>"
inserting an '*' where newer kernels will have the new br + efr fields
This makes these matches working with old as well as new kernels.
Link: https://github.com/systemd/systemd/issues/20550
Link: https://github.com/systemd/systemd/pull/20562
Let's switch from the low-level SHA256 APIs to EVP APIs. The former are
deprecated on OpenSSL 3.0, the latter are supported both by old
OpenSSL and by OpenSSL 3.0, hence are the better choice.
Fixes: #20775
It's not "const", it can change any time if people change the fs, and we
don#t send out notifications for it. Hence don't claim it was const.
(Otherwise clients might cache it, but they should not)
Prompted-by: #20792
According to the various man pages of "resolvconf" the -u switch is for:
"-u Just run the update scripts (if updating is enabled)."
"-u Force resolvconf to update all its subscribers. resolvconf does not
update the subscribers when adding a resolv.conf that matches what
it already has for that interface."
We have no "subscribers", we ourselves are the only "subscriber" we
support. Hence it's probably better to ignore such a request and make it
a NOP, then to fail.
Fixes: #20748
