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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
So far when parsing /proc/cmdline we'd consider backslashes as
mechanisms for escaping whitepace or quotes. This changes things so that
they are retained as they are instead. The kernel itself doesn't allow such
escaping, and hence we shouldn't do so either (see lib/cmdline.c in the
kernel sources; it does support "" quotes btw).
This fix is useful to allow specifying backslash escapes in the "root="
cmdline option to be passed through to systemd-fstab-generator. Example:
root=/dev/disk/by-partlabel/Root\x20Partition
Previously we'd eat up the "\" so that we'd then look for a device
/dev/disk/by-partlabel/Rootx20Partition which never shows up.
(cherry picked from commit d997861ea7dae633174cd80ab55552c020526b62)
(cherry picked from commit 0e6d3243ad3c5ae719c23e14b159c27344523583)
The words and cword variables are not localized in all Bash completion
scripts that call _init_completion.
cur, prev, words, and cword (and split if using the -s flag) are all
variables that should be localized in Bash completion scripts before
calling _init_completion (even if they don't otherwise appear in the
calling script). This is done for cur and prev, but not for words and
cword. Letting words and cword remain unlocalized may clobber variables
the user is using for other purposes, which is bad.
This issue can be resolved by declaring words and cword as local
variables.
Resolves#19188.
(cherry picked from commit f34173a048061b3f7e551e9a7c04f00e5a106fac)
(cherry picked from commit 90aee910f6e6d54e78651ee8a9d95823b88b527d)
Until now, string treated case-insensitive, always converted to
uppercase. This can cause confusion such as user enter uppercased
recovery key.
(cherry picked from commit fd11201b93c1f3c32831873b746236202f500e91)
(cherry picked from commit f1c0eea4939320b5317f58b9577a6751f289b7fe)
Since the switch to varlink in 0c73f4f075a2d23f7cabe708b589f19f4bbbec37, the
code wasn't functional. The JSON_VARIANT_UNSIGNED/JSON_VARIANT_STRING mismatch
meant that we'd reject any reply. Once past that, the code would use
unitialized 'c' and 'n' variables, so it's lucky we never got that far ;)
With -Wmaybe-unitialized, gcc would warn.
I think that declaring the huge list of local variables with very short names
at the top of the function was making it harder to understand what is going on
in the function. So let's rename the variables a bit, and initialize them upon
declaration if possible.
$ build/test-nss-hosts resolve 1.1.1.1 1.0.0.1 10.38.5.41
======== resolve ========
_nss_resolve_gethostbyaddr2_r("1.1.1.1") → status=NSS_STATUS_SUCCESS
errno=999/--- h_errno=0/Resolver Error 0 (no error) ttl=0
"one.one.one.one"
AF_INET 1.1.1.1
_nss_resolve_gethostbyaddr_r("1.1.1.1") → status=NSS_STATUS_SUCCESS
errno=999/--- h_errno=0/Resolver Error 0 (no error)
"one.one.one.one"
AF_INET 1.1.1.1
_nss_resolve_gethostbyaddr2_r("1.0.0.1") → status=NSS_STATUS_SUCCESS
errno=999/--- h_errno=0/Resolver Error 0 (no error) ttl=0
"one.one.one.one"
AF_INET 1.0.0.1
_nss_resolve_gethostbyaddr_r("1.0.0.1") → status=NSS_STATUS_SUCCESS
errno=999/--- h_errno=0/Resolver Error 0 (no error)
"one.one.one.one"
AF_INET 1.0.0.1
_nss_resolve_gethostbyaddr2_r("10.38.5.41") → status=NSS_STATUS_SUCCESS
errno=999/--- h_errno=0/Resolver Error 0 (no error) ttl=0
"squid.redhat.com"
alias "squid.corp.redhat.com"
alias "squid2.corp.redhat.com"
alias "squid3.corp.redhat.com"
alias "squid4.corp.redhat.com"
alias "squid5.corp.redhat.com"
AF_INET 10.38.5.41
_nss_resolve_gethostbyaddr_r("10.38.5.41") → status=NSS_STATUS_SUCCESS
errno=999/--- h_errno=0/Resolver Error 0 (no error)
"squid.redhat.com"
alias "squid.corp.redhat.com"
alias "squid2.corp.redhat.com"
alias "squid3.corp.redhat.com"
alias "squid4.corp.redhat.com"
alias "squid5.corp.redhat.com"
AF_INET 10.38.5.41
(I have 10.38.5.41 squid.redhat.com squid.corp.redhat.com squid2.corp.redhat.com squid3.corp.redhat.com squid4.corp.redhat.com squid5.corp.redhat.com
in /etc/hosts for testing.)
(cherry picked from commit 77fac974fe396dbe4fb679b748bfa89db1136e0c)
(cherry picked from commit 315a28e2c74efe2afb33d70f4bc83dda1424b8a1)
Introduced in 4f9ff96a55187927a4164a19df580329f4c6522b.
(cherry picked from commit 9fd8d678ba41ad39348758d5d329fe8d4451813f)
(cherry picked from commit 5ea1cd471149acdce4588a5ca7071d8adbd26adc)
Back in v232 systemd-shutdown would log to /dev/console. However after
the addition of always_reopen_console (v233) it would log to STDERR.
This caused some debugging issues as container systemd-shutdown logs
weren't being logged to console as the arg `--log-target=console` suggested.
Since it appears that always_reopen_console was intended for pid1, set
it in systemd-shutdown as well so logs will go to /dev/console.
(cherry picked from commit f975f1cc748929942188ae1490cf8480f8a64877)
(cherry picked from commit baa8bd89efa752633805c5b04b02d1dbde5ea0bb)
LLD 13 and GNU ld 2.37 support -z start-stop-gc which allows garbage
collection of C identifier name sections despite the __start_/__stop_
references. Simply set the retain attribute so that GCC 11 (if
configure-time binutils is 2.36 or newer)/Clang 13 will set the
SHF_GNU_RETAIN section attribute to prevent garbage collection.
Without the patch, there are linker errors like the following with -z
start-stop-gc.
```
ld: error: undefined symbol: __start_SYSTEMD_BUS_ERROR_MAP
>>> referenced by bus-error.c:93 (../src/libsystemd/sd-bus/bus-error.c:93)
>>> sd-bus_bus-error.c.o:(bus_error_name_to_errno) in archive src/libsystemd/libsystemd_static.a
```
(cherry picked from commit 945317a4b69d33752c9513bb8994fe8d5a786ea6)
This adds the same line to most of our .conf files.
Not for systemd/user.conf though, since we can't correctly display it right
now:
$ systemd-analyze cat-config --user systemd/user.conf
Option --user is not supported for cat-config right now.
For sysusers.d, tmpfiles.d, rules.d, etc, there is no single file. Maybe
we should short READMEs in /usr/lib/sysusers.d, /usr/lib/tmpfiles.d, etc.?
Inspired by #19118.
(cherry picked from commit 3b0754b16c5535fd48f48ca39f69335ef695efe7)
This is inspired by a recent thread on fedora-devel: it's noteworthy
when we switch to the fallback servers, since it might (or might not)
indicate some configuration problem.
Fixes: #18788
(cherry picked from commit 9b564bbca5fcfb251b7990c8642c82846d09338b)
This can happen if ifi fails to be read from the netlink message and the
error is ENODATA.
Fixes the following valgrind message when running netstat:
==164141== Conditional jump or move depends on uninitialised value(s)
==164141== at 0x524AE60: address_compare (local-addresses.c:29)
==164141== by 0x48BCC78: msort_with_tmp.part.0 (msort.c:105)
==164141== by 0x48BC9E4: msort_with_tmp (msort.c:45)
==164141== by 0x48BC9E4: msort_with_tmp.part.0 (msort.c:53)
==164141== by 0x48BCF85: msort_with_tmp (msort.c:45)
==164141== by 0x48BCF85: qsort_r (msort.c:297)
==164141== by 0x52500FC: UnknownInlinedFun (sort-util.h:47)
==164141== by 0x52500FC: local_gateways.constprop.0 (local-addresses.c:310)
==164141== by 0x5251C05: _nss_myhostname_gethostbyaddr2_r (nss-myhostname.c:456)
==164141== by 0x5252006: _nss_myhostname_gethostbyaddr_r (nss-myhostname.c:500)
==164141== by 0x498E7FE: gethostbyaddr_r@@GLIBC_2.2.5 (getXXbyYY_r.c:274)
==164141== by 0x498E560: gethostbyaddr (getXXbyYY.c:135)
==164141== by 0x121353: INET_rresolve.constprop.0 (inet.c:212)
==164141== by 0x1135B9: INET_sprint (inet.c:261)
==164141== by 0x121BFC: addr_do_one.constprop.0.isra.0 (netstat.c:1156)
(cherry picked from commit d2f4a9488ce0847da754614706fadefbca9ed2a4)
If ":" was the last char in the string, we would call access() on ".../drivers/", which
would pass. It probably doesn't matter, but let's reject this anyway.
(cherry picked from commit 52a89a5f08230439f07c043d59ded1270842137b)
(cherry picked from commit 92e5ba438d48a798807104d8aed4e480c58c6465)
No functional change intended.
(cherry picked from commit 3e2d0c6ab2abc0ab85440580931b2462bb73cfda)
(cherry picked from commit 37eeb9c03f86227e94d8e1fa046ca0c0d2b6d237)
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33881.
Not only we would duplicate unknown input on the stack, we would do it
over and over. So let's first check that the input has reasonable length,
but also allocate just one fixed size buffer.
(cherry picked from commit e17c95af8e450caacde692875b30675cea75211f)
(cherry picked from commit 5172ef4a58bda5be18dcdbbe0abd2c6bb4f08743)
Today this is v248 with 938bdfc0fa737d86eb3ecc70506e11e5f740e0dc, which,
if you don't know about the github webflow key fails to configure with
meson.build:724:8: ERROR: String "gpg: Signature made Tue 30 Mar 2021 22:59:02 CEST\ngpg: using RSA key 4AEE18F83AFDEB23\ngpg: Can't check signature: No public key\n1617137942\n" cannot be converted to int
or, if you do, with
meson.build:724:8: ERROR: String 'gpg: Signature made Tue 30 Mar 2021 22:59:02 CEST\ngpg: using RSA key 4AEE18F83AFDEB23\ngpg: Good signature from "GitHub (web-flow commit signing) <noreply@github.com>" [unknown]\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg: There is no indication that the signature belongs to the owner.\nPrimary key fingerprint: 5DE3 E050 9C47 EA3C F04A 42D3 4AEE 18F8 3AFD EB23\n1617137942\n' cannot be converted to int
(cherry picked from commit 2d945027244c02fab8d388353f034a2d82ca151b)
(cherry picked from commit 964a13d17be3426ecf539a5155e2cb8b4c16fb31)
Similar to `ProcessSizeMax`. The defaults in percentages can be misunderstood to mean the values for these parameters will be in percentages.
(cherry picked from commit 88c2c8a0ba13de31061a22a352410c18ffacab9a)
(cherry picked from commit a9ab73ca9f79d0830e71716359a9710fc165ccca)
Otherwise a coredump started at the inconvinient moment can stop
shutdown.target leaving the system in a halfway-down state:
Pulling in shutdown.target/start from systemd-poweroff.service/start
Added job shutdown.target/start to transaction.
...
Keeping job shutdown.target/start because of systemd-poweroff.service/start
...
[ OK ] Stopped target Remote File Systems.
shutdown.target: starting held back, waiting for: systemd-networkd.socket
sysinit.target: stopping held back, waiting for: remount_tmp.service
systemd-coredump.socket: Incoming traffic
...
systemd-coredump@0-243-0.service: Trying to enqueue job systemd-coredump@0-243-0.service/start/replace
Added job systemd-coredump@0-243-0.service/start to transaction.
Pulling in systemd-journald.socket/start from systemd-coredump@0-243-0.service/start
Added job systemd-journald.socket/start to transaction.
Pulling in system.slice/start from systemd-journald.socket/start
Added job system.slice/start to transaction.
Pulling in -.slice/start from system.slice/start
Added job -.slice/start to transaction.
Pulling in system-systemd\x2dcoredump.slice/start from systemd-coredump@0-243-0.service/start
Added job system-systemd\x2dcoredump.slice/start to transaction.
Pulling in system.slice/start from system-systemd\x2dcoredump.slice/start
Pulling in shutdown.target/stop from system-systemd\x2dcoredump.slice/start
Added job shutdown.target/stop to transaction.
...
Keeping job systemd-poweroff.service/stop because of umount.target/stop
Keeping job shutdown.target/stop because of systemd-coredump@0-243-0.service/start
(cherry picked from commit 4e947bd04944e58df4103eee4cb8180b5008f143)
(cherry picked from commit e11d3ec13c1ee7af65893e94d09d8b3b66cd99c9)
As commented in the code, kernel sends messages about neighbors after
a link is removed.
(cherry picked from commit 27a213392f642fdd2a9dbce914bbfda9a72aafc1)
(cherry picked from commit beaae1f8d1d958e95117550604aa6462d1a636b8)
The error is harmless, and will be ignored. Let's downgrade log level.
(cherry picked from commit 83e7c37b19bd36c78b235ac3047b758fcf82ad78)
(cherry picked from commit 1db3be80337b79e3b9afda9d50c61e6aed5aff28)
https://bugzilla.redhat.com/show_bug.cgi?id=1944171
This was in F33, systemd-246.13, but the logic in the code didn't change.
Thread 1 (Thread 0x7fb5f0341b80 (LWP 1974)):
№0 selabel_lookup_common (rec=0x0, translating=0, key=0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service", type=40960) at label.c:167
'rec' is the handle that we passed.
№1 0x00007fb5f13ae87f in selabel_lookup_raw (rec=<optimized out>, con=con@entry=0x7fffef307380, key=key@entry=0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service", type=type@entry=40960) at label.c:256
lr = <optimized out>
'rec' is passed through as is to selabel_lookup_common().
№2 0x00007fb5f1561b2d in selinux_create_file_prepare_abspath (abspath=0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service", mode=40960) at ../src/basic/selinux-util.c:368
filecon = 0x0
r = <optimized out>
__PRETTY_FUNCTION__ = "selinux_create_file_prepare_abspath"
__func__ = "selinux_create_file_prepare_abspath"
№3 0x00007fb5f1561ec3 in mac_selinux_create_file_prepare (path=<optimized out>, mode=40960) at ../src/basic/selinux-util.c:431
r = 0
abspath = 0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service"
__PRETTY_FUNCTION__ = "mac_selinux_create_file_prepare"
We checked label_hnd != NULL, but then we apparently called
avc_netlink_check_nb(), which reset label_hnd. Yay for global state!
№4 0x00007fb5f1549950 in symlink_atomic_label (from=0x55f6169d8b50 "69a8dcf7a7ac46b29306f2fddbed3edc", to=0x55f616ab8380 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service") at ../src/basic/label.c:55
r = <optimized out>
__PRETTY_FUNCTION__ = "symlink_atomic_label"
In the logs:
Mar 29 14:48:44 fedorapad.home systemd[1974]: selinux: avc: received policyload notice (seqno=2)
Mar 29 14:48:44 fedorapad.home systemd[1974]: Failed to initialize SELinux labeling handle: No such file or directory
Mar 29 14:48:44 fedorapad.home systemd[1974]: selinux: avc: received policyload notice (seqno=3)
Mar 29 14:48:44 fedorapad.home systemd[1974]: selinux: avc: received setenforce notice (enforcing=0)
(cherry picked from commit 7960ba96d165169999b6ee434a90faadb144ea5e)
We were duplicating setting flags for the message and a combination of
NLM_F_APPEND and NLM_F_CREATE which does not make sense. We should have
been using NLM_F_REPLACE and NLM_F_CREATE since the kernel can
dynamically create neighbors prior to us adding an entry. Otherwise, we
can end up with cases where the message will time out after ~25s even
though the neighbor still gets added. This delays the rest of the setup
of the interface even though the error is ultimately ignored.
(cherry picked from commit 192a9d95ea3e058afd824d38a9cea16ad0a84a57)
These were added to eficonex.h in gnu-efi 3.0.13. Let's move them
to missing_efi.h behind an appropriate guard to fix the build with
recent versions of gnu-efi.
(cherry picked from commit 95ba433a5f34baf92921fb58051bc8241f908c0e)
LoadCredentials=foo causes an assertion to be triggered, as we
are not checking that the rvalue's right hand side part is non-empty
before using it in unit_full_printf.
Fixes#19178
# printf [Service]nLoadCredential=passwd.hashed-password.rootn > hello.service
# systemd-analyze verify ./hello.service
...
Assertion 'format' failed at src/core/unit-printf.c:232, function unit_full_printf(). Aborting.
Aborted (core dumped)
Alternative title: Replace get_process_cmdline()'s fopen()/fread() with
read_full_virtual_file().
When RLIMIT_STACK is set to infinity:infinity, _SC_ARG_MAX will
return 4611686018427387903 (depending on the system, but definitely
something larger than most systems have). It's impractical to allocate this
in one go when most cmdlines are much shorter than that.
Instead use read_full_virtual_file() which seems to increase the buffer
depending on the size of the contents.
(cherry picked from commit 7b7a060e83d6c7de8705904d71978ba4664f0a65)
The generated string may include %, which will confuse both the
xprintf call, and the VA_FORMAT_ADVANCE macro.
Pass the generated string as an argument to a "%s" format string
instead.
(cherry picked from commit 7325a2b2d15af09a9389723d6153050130c0bd36)
The encapsulation limit of IPv6 tunnel can not be set to 4, which is the default value of the encapsulation limit.
(cherry picked from commit 6b1ed5e7e68fc5992a7bdabe4a05a7a3e1e1d898)
