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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes a bug introduced by 8b49ee2dcda04f8147650f7d9fb93662caf3ea2e.
Fixes#26011.
(cherry picked from commit bf4a5ac804d85a1e8df8226e8595219aa6fdafae)
(cherry picked from commit 33e6d133819c8b4b9468a16caf222ceb6ef39437)
CURLOPT_PROTOCOLS [0] was deprecated in libcurl 7.85.0 with
CURLOPT_PROTOCOLS_STR [1] as a replacement, causing build warnings/errors:
../build/src/import/curl-util.c: In function ‘curl_glue_make’:
../build/src/import/curl-util.c:255:9: error: ‘CURLOPT_PROTOCOLS’ is deprecated: since 7.85.0. Use CURLOPT_PROTOCOLS_STR [-Werror=deprecated-declarations]
255 | if (curl_easy_setopt(c, CURLOPT_PROTOCOLS, CURLPROTO_HTTP|CURLPROTO_HTTPS|CURLPROTO_FILE) != CURLE_OK)
| ^~
In file included from ../build/src/import/curl-util.h:4,
from ../build/src/import/curl-util.c:6:
/usr/include/curl/curl.h:1749:3: note: declared here
1749 | CURLOPTDEPRECATED(CURLOPT_PROTOCOLS, CURLOPTTYPE_LONG, 181,
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Since there's no grace period between the two symbols, let's resort
to a light if-def-ery to resolve this.
[0] https://curl.se/libcurl/c/CURLOPT_PROTOCOLS.html
[1] https://curl.se/libcurl/c/CURLOPT_PROTOCOLS_STR.html
(cherry picked from commit e61a4c0b7c79eabbe4eb50ff2e663734fde769f0)
(cherry picked from commit 14f573175aa6a026c03fd09dea5952f3755b799a)
CURLINFO_PROTOCOL has been deprecated in curl 7.85.0 causing compilation
warnings/errors:
../build/src/import/pull-job.c: In function ‘pull_job_curl_on_finished’:
../build/src/import/pull-job.c:142:9: error: ‘CURLINFO_PROTOCOL’ is deprecated: since 7.85.0. Use CURLINFO_SCHEME [-Werror=deprecated-declarations]
142 | code = curl_easy_getinfo(curl, CURLINFO_PROTOCOL, &protocol);
| ^~~~
In file included from ../build/src/import/curl-util.h:4,
from ../build/src/import/pull-job.h:6,
from ../build/src/import/pull-common.h:7,
from ../build/src/import/pull-job.c:16:
/usr/include/curl/curl.h:2896:3: note: declared here
2896 | CURLINFO_PROTOCOL CURL_DEPRECATED(7.85.0, "Use CURLINFO_SCHEME")
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Since both CURLINFO_SCHEME and CURLINFO_PROTOCOL were introduced in
the same curl version (7.52.0 [0][1]) we don't have to worry about
backwards compatibility.
[0] https://curl.se/libcurl/c/CURLINFO_SCHEME.html
[1] https://curl.se/libcurl/c/CURLINFO_PROTOCOL.html
(cherry picked from commit 2285c462ebb0b5d9a7043719a4f0d684a5dc37c2)
(cherry picked from commit 4ab37502b35c76441b7be656b67ef53024af8a9f)
Inspired by #25957 there's one other place where we don't guard
acl_free() calls with a NULL check.
Fix that.
(cherry picked from commit 34680637e838415204850f77c93ca6ca219abaf1)
(cherry picked from commit 4dabf90526d4573144a51bdd87c1203b25265b33)
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab04d566ff745849e1c4ced680a0447cf76)
(cherry picked from commit a11a949c43def70ec5d3f57f561884c3f652603e)
Let's pass USEC_INFINITY from sd_event_source_set_time_relative() to
sd_event_source_set_time() instead of raising EOVERFLOW.
We should raise EOVERFLOW only if your addition fails, but not if the
input already is USEC_INFINITY, since it's an entirely valid operation
to have an infinite time-out, and we should support that.
(cherry picked from commit ef8591951aefccb668201f24aa481aa6cda834da)
(cherry picked from commit 9769d84fe51573b4f2d5cb8f76664e886c7daf88)
The second argument to dump_list() actually ends up in a TABLE_FIELD
cell now, where we implicitly append a ":". Hence drop it from the
strings.
Follow-up for: 37a50123fac050c7ccde4afcf3f37ee77aad012c
(cherry picked from commit ef503f1cec53f654780591adee6e3e223b575f56)
(cherry picked from commit c01cdcfb8a38e8e0eadf6feab71fe6547b1acc1d)
Previously, if a client disconnected after sending a lookup request but
before waiting for the reply we'd log at LOG_ERR level. That's
confusing, since it's entirely OK for the client to lose interest.
Hence, let's downgrade to debug level.
Fixes: #25892
(cherry picked from commit 40557509be084f27d48bc5fc51286a664b96942e)
(cherry picked from commit a3ceaf0f1d844b27c2b11704b43e9da59a0ef39d)
cannot pass false as argument because function wants a pointer to bool
instead, use NULL instead
(cherry picked from commit 2cc697d7400446a7ea823bc38061501cd85b046a)
(cherry picked from commit e78a1489a8c2b398ad30a8d868754601876ba3d2)
GCC-13 -std=gnu2x FTBS with:
error: incompatible type for argument 3 of ‘_hashmap_free’
(cherry picked from commit a4a1569ff1e9ab62996f8b42dcc14a09f91b5715)
(cherry picked from commit 921bff2f856762c4c98912394f1b6b54ed063bbd)
../src/basic/cgroup-util.c: In function ‘skip_session’:
../src/basic/cgroup-util.c:1241:32: error: incompatible types when returning type ‘_Bool’ but ‘const char *’ was expected
1241 | return false;
(cherry picked from commit db8e720984269a050a7a78aeb503a7402ef567f7)
(cherry picked from commit ad647734c7cffeab0f44b12411f0e123083e9db1)
We treat any negative value as "invalid fd", but signalfd only
accepts -1.
(cherry picked from commit cbff793ffb280d9d11e5d7b1dc3964276491bee8)
(cherry picked from commit 54c840ea58c578060e941f754a4fed2931483820)
If the page size of a swap space doesn't match the page size of the
currently running kernel, swapon will fail. Let's instruct it to
reinitialize the swap space instead.
(cherry picked from commit cc137d53e36da5e57b060be5e621864f572b2cac)
(cherry picked from commit a0ac79bce9255cf33b0f208b18d888f0f700133c)
After #25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.
Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.
Fixes#19208.
(cherry picked from commit e6319a102e5b6f7c1588ca851d66db7c3ade1665)
(cherry picked from commit 892cb01c2b6373b6ec870b24e8ab1774d511758a)
As we filtered out network devices in the test.
(cherry picked from commit 733529d81227ca713de2d6be77939e3bfedb926f)
(cherry picked from commit a8dd94e0cc162d3d020d49af7d1e238b9c7afca3)
This ensures that services with `RemainAfterExit` but without any
process running won't cause failure during freeze.
(cherry picked from commit fcb0878f7563df9701a4d066378995c0b7ec32be)
(cherry picked from commit 2eb040f36f65c316c0d015d024faf9d27db10821)
Explicitly set __attribute__ ((noinline)) so that the compiler does not
attempt to inline expand_to_usable, even with LTO.
(cherry picked from commit 4f79f545b3c46c358666c9f5f2b384fe50aac4b4)
(cherry picked from commit e998c9d7c1a52ab02ff6e9c363c1cfe0b76cd6f4)
systemd uses malloc_usable_size() everywhere to use memory blocks
obtained through malloc, but that is abuse since the
malloc_usable_size() interface isn't meant for this kind of use, it is
for diagnostics only. This is also why systemd behaviour is flaky when
built with _FORTIFY_SOURCE.
One way to make this more standard (and hence safer) is to, at every
malloc_usable_size() call, also 'reallocate' the block so that the
compiler can see the larger size. This is done through a dummy
reallocator whose only purpose is to tell the compiler about the larger
usable size, it doesn't do any actual reallocation.
Florian Weimer pointed out that this doesn't solve the problem of an
allocator potentially growing usable size at will, which will break the
implicit assumption in systemd use that the value returned remains
constant as long as the object is valid. The safest way to fix that is
for systemd to step away from using malloc_usable_size() like this.
Resolves#22801.
(cherry picked from commit 7929e180aa47a2692ad4f053afac2857d7198758)
(cherry picked from commit 34b9eddfc12936917fab000b780a451d6277c2b4)
gcc 13 -Wenum-int-mismatch reminds us that enum != int
(cherry picked from commit e14afe31c3e8380496dc85b57103b2f648bc7d43)
(cherry picked from commit ba5f7915d25a400f0651bc9e8546a3ec6a738eaa)
Fixes gcc 13 -Wenum-int-mismatch which are enabled by default.
(cherry picked from commit aa70dd624bff6280ab6f2871f62d313bdb1e1bcc)
(cherry picked from commit b1b7667a44c4e8635b6d8dc070fb2446187fcdc5)
Commit 1b86c7c59ecc ("virt: make virtualization enum a named type")
made the conversion from `if (!r)` to `if (v != VIRTUALIZATION_NONE)`.
However, the initial test was meaning "if r is null", IOW "if r IS
`VIRTUALIZATION_NONE`).
The test is wrong and this can lead to false detection of the container
environment (when calling `systemctl exit`).
For example, https://gitlab.freedesktop.org/whot/libevdev/-/jobs/34207974
is calling `systemctl exit 0`, and systemd terminates with the exit code
`130`.
Fixing that typo makes `systemctl exit 0` returns `0`.
Fixes: 1b86c7c59ecc26efdf278f5c1c4430346021cd38.
(cherry picked from commit a91078bc57950c9b0c19fd25fb2e802409695304)
This reverts commit 64f0e5385139a86f2df7f78fa67ade2075726db5.
On Wed, Dec 21, 2022 at 06:19:08PM +0100, Marius Schwarz wrote:
> That patch made things worse and is disfunctional for both, usb drive and
> password.
>
> No idea if more patches are needed, but this build does not unlock a drive
> at all, if usb is configured.
When the user starts a program which elevates its permissions via setuid,
setgid, or capabilities set on the file, it may access additional information
which would then be visible in the coredump. We shouldn't make the the coredump
visible to the user in such cases.
Reported-by: Matthias Gerstner <mgerstner@suse.de>
This reads the /proc/<pid>/auxv file and attaches it to the process metadata as
PROC_AUXV. Before the coredump is submitted, it is parsed and if either
at_secure was set (which the kernel will do for processes that are setuid,
setgid, or setcap), or if the effective uid/gid don't match uid/gid, the file
is not made accessible to the user. If we can't access this data, we assume the
file should not be made accessible either. In principle we could also access
the auxv data from a note in the core file, but that is much more complex and
it seems better to use the stand-alone file that is provided by the kernel.
Attaching auxv is both convient for this patch (because this way it's passed
between the stages along with other fields), but I think it makes sense to save
it in general.
We use the information early in the core file to figure out if the program was
32-bit or 64-bit and its endianness. This way we don't need heuristics to guess
whether the format of the auxv structure. This test might reject some cases on
fringe architecutes. But the impact would be limited: we just won't grant the
user permissions to view the coredump file. If people report that we're missing
some cases, we can always enhance this to support more architectures.
I tested auxv parsing on amd64, 32-bit program on amd64, arm64, arm32, and
ppc64el, but not the whole coredump handling.
(cherry picked from commit 3e4d0f6cf99f8677edd6a237382a65bfe758de03)
(cherry picked from commit 9b75a3d0502d6741c8ecb7175794345f8eb3827c)
It may take a bit for newly introduced binaries/other files to get
properly integrated into the Rawhide specfile, so don't choke up in the
meantime when rpmbuild detects unpackaged files.
(cherry picked from commit ed7c45a8c81bb0f82048b9e6dd285b234e3c5b7f)
(cherry picked from commit 689161a30137350a1a855ef0f38b2f043a4d3802)
In both cases, the json string is short, so we can print it, which is useful
for diagnosing invalid data in packages. But we need escape non-printable
characters.
https://bugzilla.redhat.com/show_bug.cgi?id=2152685
I went over the rest of the codebase, and it seems that other calls to
json_parse() don't have this problem.
(cherry picked from commit c5966ab5bf43b4fb45998760beaffa6c7f9e8a9e)
(cherry picked from commit 57ab4e2d47dd7c03113b66b78175242a597bd0dc)
Let's enforce that callers pass AT_FDCWD as read_dfd to load_credential()
to avoid an assert() in read_full_file_full() if read_dfd is -1.
(cherry picked from commit 661e4251a5b157d1aee1df98fbd2f0c95285ebba)
(cherry picked from commit d78dc885b0daca940845668a3d51412b2d01cf18)
We would execute up to four hwdb match patterns (+ the keyboard builtin):
After the first hit, we would skip the other patterns, because of the GOTO="evdev_end"
action.
57bb707d48131f4daad2b1b746eab586eb66b4f3 (rules: Add extended evdev/input match
rules for event nodes with the same name), added an additional match with
":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user
hwdb patterns, because we quit after the first match.
In general hwdb properties are "additive". We often have a general rule that
matches a wider class and then some specific overrides. E.g. in this particular
case, we have a match for all trackpoints, and then a bunch of model-specific
settings.
So let's change the rules to try all the match patterns and combine the
received properties. We execute builtin-keyboard once at the end, if there was
at least one match.
Fixes#25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226.
This also impacts other cases which I think would be very confusing for users.
Since we quit after a first successful match, if we had e.g. a match for
'evdev:input:b*v*p*' in out database, and the user added a match using
'evdev:name:*', which is the approach we document in the .hwdb files and which
users quite often use, it would be silently ignored. What's worse, if we added
our 'evdev:input:b*v*p*' match at a later point, user's match would stop
working. If we combine all the properties, we get more stable behaviour.
(cherry picked from commit 953c928c24455744d5534679998d129b947a5e04)
(cherry picked from commit 4cfdb1c73b1d3ce1ddbd4685eded06b2ccdb42e0)
Otherwise, if a device is removed while switching root, then the
corresponding .device unit will never go to inactive state.
This replaces the code dropped by cf1ac0cfe44997747b0f857a1d0b67cea1298272.
Fixes#25106.
(cherry picked from commit b6c86ae28149c4abb2f0bd6acab13153382da9e7)
(cherry picked from commit e3d9376692318e3d88077ca81d99ea3552b4d5f6)
Upstream comment says this is for cf1… which is post-v251, but the buggy commit
was backported to v251-stable.
The field will be used in later commits.
(cherry picked from commit 1ea74fca3a3c737f3901bc10d879b7830b3528bf)
(cherry picked from commit 9523f85b2ecb5088a08ff9a3037459623bf774f5)
If an attribute is read but the value is not used (i.e. ret_value is NULL),
then sd_device_get_sysattr_value() mistakenly frees the read data even though
it is cached internally.
Fixes a bug introduced by acfc2a1d15560084e077ffb3be472cd117e9020a.
Fixes#25702.
(cherry picked from commit eb18e7b7825e8320bb4d6269690ef8c3f5461d2b)
(cherry picked from commit aeb36537443272f0bf73dd672837eabcecb34f3a)
This effectively reverts 5d0030310c134a016321ad8cf0b4ede8b1800d84.
With the commit 5d0030310c134a016321ad8cf0b4ede8b1800d84, networkd manages
addresses with the detailed hash and compare functions. But that causes
networkd cannot detect address update by the kernel or an external tool.
See issue
https://github.com/systemd/systemd/issues/481#issuecomment-1328132401.
With this commit, networkd (again) manages addresses in the way that the
kernel does. Hence, we can correctly detect address update.
(cherry picked from commit 42f8b6a80878e688b821adfb315c0a1f0a7076ce)
(cherry picked from commit 13de548fca2d18d1f900d82201301a109accef25)
Btrfs quotas are actually being enabled in systemd-importd via
setup_machine_directory(), not in systemd-{import,pull} where those
environment variables are checked. Therefore, also check them in
systemd-importd and avoid enabling quotas if requested by the user.
Fixes: #18421Fixes: #15903Fixes: #24387
(cherry picked from commit c7779a61ac20133646aaeaee2986d4e0901f4861)
(cherry picked from commit fcc174cbdd9e0d9f9d2db87ee8020a8397136bda)
Non-negative return values of setup_machine_directory() were never used
and never had clear meaning, so do not distinguish between various
non-error conditions and just return 0 in all cases.
(cherry picked from commit e9231901a2df0484b1eda70d6bed9f4f7cefac64)
(cherry picked from commit 6cb0724a062405071850ddae53eb07f63507d786)
