This reverts commit 097537f07a.
At least Fedora and Debian have already reverted this at the distro
level because it causes more problems than it solves. Arch is debating
reverting it as well [0] but would strongly prefer that this happens
upstream first. Fixes#15188.
[0] https://bugs.archlinux.org/task/66458
Since #15533 we didn't create the mount point for selinuxfs anymore.
Before it we created it twice because we mount selinuxfs twice: once the
superblock, and once we remount its bind mound read-only. The second
mkdir would mean we'd chown() the host version of selinuxfs (since
there's only one selinuxfs superblock kernel-wide).
The right time to create mount point point is once: before we mount the
selinuxfs. But not a second time for the remount.
Fixes: #16032
We'd try to map a zero-byte buffer from a NULL pointer, which is undefined behaviour.
src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60: runtime error: applying zero offset to null pointer
#0 0x7f6ff064e691 in find_part /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60
#1 0x7f6ff0640788 in message_peek_body /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3283:16
#2 0x7f6ff064e8db in enter_struct_or_dict_entry /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3967:21
#3 0x7f6ff06444ac in bus_message_enter_struct /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4009:13
#4 0x7f6ff0641dde in sd_bus_message_enter_container /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4136:21
#5 0x7f6ff0619874 in sd_bus_message_dump /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-dump.c:178:29
#6 0x4293d9 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bus-message.c:39:9
#7 0x441986 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15
#8 0x44121e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
#9 0x443164 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7
#10 0x4434bc in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3
#11 0x42d2bc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6
#12 0x42978a in main /src/libfuzzer/FuzzerMain.cpp:19:10
#13 0x7f6fef13c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#14 0x407808 in _start (out/fuzz-bus-message+0x407808)
Access to bit fields is less efficient, and since the Manager is a singleton,
a byte or two of space in the structure doesn't matter at all. (And in this
particular case, because of alignment issues, we wouldn't save anything
anyway.)
The key macros added in commit 6fe95d3020 look strange at first sight.
Add a comment with just the tablet name after each line, so that it's
obvious that these lines address device-specific issues of the EFI
firmware, and not broken/old code.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
This is an attempt to clean up the POP3/SMTP/LPR/… DHCP lease server
data logic in networkd. This reduces code duplication and fixes a number
of bugs.
This removes any support for collecting POP3/SMPT/LPR servers acquired
via local DHCP client releases since noone uses that, and given how old
these protocols are I doubt this will change. It keeps support for
configuring them for the dhcp server however.
The differences between the DNS/NTP/SIP/POP3/SMTP/LPR configuration
logics are minimized.
This removes the relevant symbols from sd-network.h (which is an
internal API only at this point after all).
This is unfortunately not well test, given the old code for this had
barely any tests. But the new code should not perform worse at least,
and allow us to release, since it corrects some interfaces visible in
the .network configuration format.
Fixes: #15943
../src/core/main.c: In function 'main':
../src/core/main.c:2637:32: error: implicit declaration of function 'cache_efi_options_variable'; did you mean 'systemd_efi_options_variable'? [-Werror=implicit-function-declaration]
(void) cache_efi_options_variable();
^~~~~~~~~~~~~~~~~~~~~~~~~~
systemd_efi_options_variable
Strictly speaking this is a compat breakage, but given the tool was
added only in the last release, let's try to sail under the radar, and
fix this early before anyone notices it wasn't supported always.
When a key is pressed, the EFI firmware gives us a 64-bit word that
contains the modifier key code in the upper 32 bits, the scan code in
the middle 16 bits, and a unicode character in the low 16 bits.
Some bogus EFI firmwares will put the unicode character in the scan code
area, for instance on the EZpad mini 4s tablet.
Others will even put the unicode character in both the scan code and
unicode areas. This is the case for instance on the Teclast X98+ II
tablet.
Add workarounds for these corner cases, only for the carriage return key
right now. Some more workarounds may be needed, e.g. for volume keys,
but I cannot test it.
Partially fixes#8466.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
The original logic was logging an "ignored" debug message, but it was still
going ahead and calling proc_cmdline_parse_given() on the NULL line. Fix that
to skip that explicitly when the EFI variable wasn't really read.
Depending on if the system has been scheduled for shutdown or for reboot pring the corresponding message (and not only "Shutdown"). Prtinting the "wrong" message when rebooting will mislead and panic people. I get these messages via cron from remote servers and it would be bad if those systems actually *did* shut down, as the email from cron is telling me. Those messages cause an adrenalin spike in our team, which wouldn't happen, if the message was "correct"
Fixes#16129.
Cache it early in startup of the system manager, right after `/run/systemd` is
created, so that further access to it can be done without accessing the EFI
filesystem at all.
The only way to control "ShowStatus" property programmatically was to use the
signal API and wait until the property "ShowStatus" switched to the new value.
This interface is rather cumbersome to use and doesn't allow to temporarily
override the current setting and later restore the overridden value in
race-free manner.
The new method also accepts the empty string as argument which allows to
restore the initial value of ShowStatus, ie the value before it was overridden
by this method.
Fixes: #11447.
Luca Boccassi
Dave Reisner
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Yu Watanabe
Paul Cercueil
Susant Sahani
Filipe Brandenburger
Tomáš Pospíšek
Jan Palus
Evgeny Vereshchagin
Franck Bui