In commit da1921a5c3 ppc64/ppc64el were added as supported architectures for
socketcall() for the POWER family. Extend the support for the 32bits
architectures.
Commit 563dc6f8e2 added support for
/etc/{passwd,group} only but since nsswitch.conf(5) appears to document the NIS
entries also for shadow, let's support this case too.
Even if pager_open() fails, in general, we should continue the operations.
All erroneous cases in pager_open() show log message in the function.
So, it is not necessary to check the returned value.
Once upon a time shutdown.c didn't have the logic to check whether any
unmount attempts succeeded or not. So instead it kept looping for
a fixed amount and hoped all was right. Nowadays, we do know if we
changed anything during a iteration and also stop looping then, but
we still limit ourselves to FINALIZE_ATTEMPTS.
But, theoretically, we could have such a complicated and nested
setup that would survive that limit, leaving stuff around we
might actually be able to unmount. And we could also end up in a
situation where the extra loop with raised unmount error level could
be skipped too.
So let's just drop the retries logic and rely fully on the changed
flag.
It's common for sysusers files to contain quotes (in particular around the
comment/GECOS field), and using echo "..." is very likely to not work properly
in that case. Let's use <<EOF redirection. It's not bulletproof, but should
work in general.
path_is_normalized() will reject paths longer than 4095 bytes, so it's better
to not create a stack variable of unbounded size, but instead do the check first
and only then do that allocation.
Also use _cleanup_ to make things a bit shorter.
https://oss-fuzz.com/v2/issue/5424177403133952/7000
msan doesn't understand sscanf with %ms, so it falsely reports unitialized
memory. Using sscanf with %ms is quite convenient in
socket_address_parse_netlink(), so let's just not run the fuzzer for
ListenNetlink= at all for now. If msan is fixed, we can remove this.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6884
Support was killed in kernel 4.15 as well as ethtool 4.13.
Justification was lack of use by drivers and too much of a maintenance burden.
https://www.spinics.net/lists/netdev/msg443815.html
Also moved config_parse_warn_compat to conf-parser.[ch] to fix compile errors.
The orignal reproducer from oss-fuzz depends on the hostname (via %H and %c).
The hostname needs a dash for msan to report this, so a simpler case from
@evverx with the dash hardcoded is also added.
The issue is a false positive from msan, which does not instruct stpncpy
(https://github.com/google/sanitizers/issues/926). Let's add a work-around
until this is fixed.
We have only three bits of space, i.e. 8 possible classes. Immediately reject
anything outside of that range. Add the fuzzer test case and an additional
unit test.
oss-fuzz #6908.
We probably should allow very deep calls of our recursive functions. Let's add
a limit to avoid resource exhaustion. 240 is 10 per hour (if somebody is using
this for time based triggers...), so it should be more than enough for most use
cases, and is conveniently below the 250 stack limit in msan.
oss-fuzz #6917.
Also fix one case where the presence of a newline was used to generate
an invalid environment assignment.
Tested: with mkosi, which builds the local tree and run ninja tests.
manager_recheck_journal() and manager_recheck_dbus() would be called to early
while we were deserialiazing units, before the systemd-journald.service and
dbus.service have been deserialized. In effect we'd disable logging to the
journald and close the bus connection. The first is not very noticable, it
mostly means that logs emitted during deserialization are lost. The second is
more noticeable, because manager_recheck_dbus() would call bus_done_api() and
bus_done_system() and close dbus connections. Logging and bus connection would
then be restored later after the respective units have been deserialized.
This is easily reproduced by calling:
$ sudo gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1 --method "org.freedesktop.systemd1.Manager.Reload"
which works fine before 8559b3b75c, and then starts failing with:
Error: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected
None of this should happen, and we should delay changing state until after
deserialization is complete when reloading. manager_reload() already included
the calls to manager_recheck_journal() and manager_recheck_dbus(), so the
connection state will be updated after deserialization during reloading is done.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1554578.
example.swaps with "(deleted)" does not cause bogus entries in the list now,
but a memleak in libmount instead. The memleaks is not very important since
this code is run just once.
Reported as https://github.com/karelzak/util-linux/issues/596.
$ build/test-umount
...
/* test_swap_list("/proc/swaps") */
path=/var/tmp/swap o= f=0x0 try-ro=no dev=0:0
path=/dev/dm-2 o= f=0x0 try-ro=no dev=0:0
/* test_swap_list("/home/zbyszek/src/systemd/test/test-umount/example.swaps") */
path=/some/swapfile o= f=0x0 try-ro=no dev=0:0
path=/dev/dm-2 o= f=0x0 try-ro=no dev=0:0
==26912==
==26912== HEAP SUMMARY:
==26912== in use at exit: 16 bytes in 1 blocks
==26912== total heap usage: 1,546 allocs, 1,545 frees, 149,008 bytes allocated
==26912==
==26912== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
==26912== at 0x4C31C15: realloc (vg_replace_malloc.c:785)
==26912== by 0x55C5D8C: _IO_vfscanf (in /usr/lib64/libc-2.26.so)
==26912== by 0x55D8AEC: vsscanf (in /usr/lib64/libc-2.26.so)
==26912== by 0x55D25C3: sscanf (in /usr/lib64/libc-2.26.so)
==26912== by 0x53236D0: mnt_table_parse_stream (in /usr/lib64/libmount.so.1.1.0)
==26912== by 0x53249B6: mnt_table_parse_file (in /usr/lib64/libmount.so.1.1.0)
==26912== by 0x10D157: swap_list_get (umount.c:194)
==26912== by 0x10B06E: test_swap_list (test-umount.c:34)
==26912== by 0x10B24B: main (test-umount.c:56)
==26912==
==26912== LEAK SUMMARY:
==26912== definitely lost: 16 bytes in 1 blocks
==26912== indirectly lost: 0 bytes in 0 blocks
==26912== possibly lost: 0 bytes in 0 blocks
==26912== still reachable: 0 bytes in 0 blocks
==26912== suppressed: 0 bytes in 0 blocks
