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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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)
- add missing assertions,
- use size_t for buffser size or memory index,
- handle empty input more gracefully,
- return the length or the result string,
- fix off-by-one issue when the prefix is already long enough.
(cherry picked from commit c21b316964357f40b8785a8869cbb280e59d3b79)
(cherry picked from commit acb0414a1f96b2cc31147f8cdeb5115b880048bb)
Inspired by #25664: let's check explicitly for NULL everywhere we do one
of those getXYZcon() calls.
We usually turn this into EOPNOTSUPP, as when selinux is off (which is
supposed to be the only case this can happen according to selinux docs)
we otherwise return EOPNOTSUPP in that case.
Note that in most cases we have an explicit mac_selinux_use() call
beforehand, hence this should mostly not be triggerable codepaths.
(cherry picked from commit af614e45c3efb49e37c4b1507ccc4e450119c089)
(cherry picked from commit 6c869ad3bdbf80da0ab2858885d3108738a017ff)
Otherwise, the dry run isn't much use since it would be logged at debug
and not seen.
(cherry picked from commit 3b703840d966b34bcf3b069a03e8cdfe7c1c2439)
(cherry picked from commit 0fdeb7c6408c785e15b729e51bf04ef359601376)
getpidcon() might set con to NULL, even when it returned a 0 return
code[0]. The subsequent strlen(con) will then cause a segfault.
Alternatively the behaviour could also be changed in getpidcon. I
don't know whether the libselinux folks are comitted to the current
behaviour, but the getpidcon man page doesn't really make it obvious
this case could happen.
[0] fb7f35495f/libselinux/src/procattr.c (L155-L158)
(cherry picked from commit ff868eaadecde2568d1e08a375ec8a3b327984fa)
(cherry picked from commit 4119d25e621b5e5b7860e971092239379768081c)
Fixes a bug introduced by 3b3557c410c7910fae0990599dcb82711cf5fbb7.
Fixes#25625.
(cherry picked from commit 47c57b4813c81187db86ed6e33ecf11f8a25825a)
(cherry picked from commit 6fdf196f99661dd70266f1140b951034713a7006)
Issue:
When device is in bond mode and booting up, there is a probability of
set bond MAC address failed due to `Device or resource busy` error.
In systemd-networkd, set MAC address steps are:
1. Try to set MAC address to device.
2. If failed with `Device or resource busy`, then `Down` the device.
3. Try to set MAC address to device again.
Currently, Even down the bond device, the bond device is still return
`Device or resource busy` error. So the MAC address set failed.
The root cause is that this not enough to down the bond device. We need
to down all the slaves of the bond device.
About this descprition, we could use those commands to check:
```shell
We have two network devices: eth0, bond1, eth0 is slave of bond1.
They are all up.
1. Down bond1, and set MAC address to bond1.
~# ip link set bond1 down
~# ip link set bond1 address 00:11:22:33:44:55
ip: SIOCSIFHWADDR: Device or resource busy
2. Down eth0, and set MAC address to bond1.
~# ip link set eth0 down
~# ip link set bond1 address 00:11:22:33:44:55
Set okay.
```
Fix:
When setting the mac for the second time, if the device kind is bond,
then we need to down the slave devices of bond device.
Tested: Verified in a long time test( reboot cycles ).
Fixes: #25627
Signed-off-by: Jian Zhang <zhangjian.3032@bytedance.com>
(cherry picked from commit f1a69d5accfd566c5af0210115f4b4a9743425ee)
(cherry picked from commit 6405eba4b641e6e9b6bf1e87679cd08ff5b48155)
Fixes a bug introduced by 95052df3760523e1f3bb9705c918d85aae7fb431.
This also makes octescape() support NULL or zero length string.
Fixes [oss-fuzz#54059](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=54059).
Fixes#25643.
(cherry picked from commit 76519cecc749a3d0e2054fd6db8a99143666e123)
(cherry picked from commit 2ea5de7881edcd1665207bb55bfd5ae2b6ccdc10)
When an interface goes to down, the kernel drops several routes
automatically, and at the same time networkd requests to remove
them, but the kernel sometimes does not respond the requests. Hence,
the routes cannot drop the REMOVING flag, and networkd will never try
to configure other routes which depend on the previously removed
routes even if they are already reconfigured.
With this patch, when networkd sends a request to configure a route
(or any other network settings), REMOVING flag for the route is dropped
without waiting for the reply about the previous remove request, as we
can expect it will appear even if it is already removed or under removing.
Fixes#24999.
(cherry picked from commit f4ee7b98c434bc9a0f436c29fd32225acd73e183)
(cherry picked from commit 8999727a82694327256857d1bc5f97d53a5696e6)
The journal has a mechanism to log to the runtime journal if it fails to
log to the system journal. This mechanism is not triggered when the file
system becomes read-only. We enable it here.
When appending an entry fails if shall_try_append_again returns true,
the journal is rotated. If the FS is read-only, rotation will fail and
s->system_journal will be set to NULL. After that, when find_journal
will try to open the journal since s->system_journal will be NULL, it
will open the runtime journal.
(cherry picked from commit 379864f89079a92ff09917e25b3aea0fadd228ac)
(cherry picked from commit 278a97708b08927d79d294b49874da39cb871ba8)
If the RDATA is of zero length, the text representation contains only
the \# token and the single zero representing the length.
(cherry picked from commit 84f788d6699f289160d7cb3823c1bf9a3826f11f)
(cherry picked from commit 44984e15bba93ee1d15af7d841f0cb41dfba3ad3)
When booting with debug logs, we print:
Setting '/proc/sys/fs/file-max' to '9223372036854775807
'
Setting '/proc/sys/fs/nr_open' to '2147483640
'
Couldn't write fs.nr_open as 2147483640, halving it.
Setting '/proc/sys/fs/nr_open' to '1073741816
'
Successfully bumped fs.nr_open to 1073741816
The strange formatting is because we explicitly appended a newline in those two
places. It seems that the kernel doesn't care. In fact, we have a few dozen other
writes to sysctl where we don't append a newline. So let's just drop those here
too, to make the code a bit simpler and avoid strange output in the logs.
(cherry picked from commit b47e0fac0356308cf34aa235ba9328c0c9de51bd)
(cherry picked from commit d59009dc1d5dbbf101fa1adfc7bc3b5e4f684267)
reset_terminal_fd sets certain minimum required terminal attributes
that systemd relies on.
One of those attributes is `ONLCR` which ensures that when a new line
is sent to the terminal, that the cursor not only moves to the next
line, but also moves to the very beginning of that line.
In order for `ONLCR` to work, the terminal needs to perform output
post-processing. That requires an additional attribute, `OPOST`,
which reset_terminal_fd currently fails to ensure is set.
In most cases `OPOST` (and `ONLCR` actually) are both set anyway, so
it's not an issue, but it could be a problem if, e.g., the terminal was
put in raw mode by a program and the program unexpectedly died before
restoring settings.
This commit ensures when `ONLCR` is set `OPOST` is set too, which is
the only thing that really makes sense to do.
(cherry picked from commit 9fe26523a189435d75b9d745188e09c17928d89e)
(cherry picked from commit 787b2c32f33225df7359bddf101b8aec4d7754fe)
Follow-up for da15f8406e9aeb7908e1d92c02d2ff5147c7788a which did the
change for systemd-networkd-wait-online.service, let's also do this for
systemd-networkd-wait-online@.service
(cherry picked from commit 51f3dc2234082c1ca9bdda403e4f355cab6be03b)
(cherry picked from commit c7bf13b2d96d5e234d5e896a960661d7561cade6)
--recursive=no will overwrite possible -P or -k option hence making the
recursive disabling impossible.
Check what counting types the system supports (encoded in the ordering
of our enum) of and pick whatever user requests but is also supported.
Fixes: #25248
(cherry picked from commit 48600b3524afe05d0faa8a5c88b5aaa53b801199)
(cherry picked from commit b97c1c427c2156495e141c736babbccabba7265d)
Filenames to store user linger requests are created with C-escaping.
When we enumerate the files to acquire ligering users, we use the
filenames verbatim. In the case C-escaping is not an identity map (such
as "DOMAIN\User"), we won't be able to start user instances of
such mangled users.
Unescape filenames when we treat them as usernames again.
Fixes: #25448
(cherry picked from commit f38e89c23ce52efa27bb47f5c3dafecdb987492b)
(cherry picked from commit 6cbf72a8d9976ba182587cf62e2b7b8ae00ae2dd)
We don't want systemd-networkd-wait-online to start if systemd-networkd
is skipped due to condition failures. This is only guaranteed by BindsTo=
and not Requires=, so let's use BindsTo=
(cherry picked from commit da15f8406e9aeb7908e1d92c02d2ff5147c7788a)
(cherry picked from commit 01a39e96b523c06d99499a28451b24f12f8ecd4b)
