With an intentional mistake:
../src/login/logind-dbus.c: In function ‘bus_manager_log_shutdown’:
../src/login/logind-dbus.c:1542:39: error: format ‘%s’ expects a matching ‘char *’ argument [-Werror=format=]
1542 | LOG_MESSAGE("%s %s", message),
| ^~~~~~~
Also break some long lines for more uniform formatting. No functional change.
I went over all log_struct, log_struct_errno, log_unit_struct,
log_unit_struct_errno calls, and they seem fine.
This is trivially exploitable (in the sense of causing a crash from SEGV) e.g.
by 'shutdown now "Message %s %s %n"'. The message is settable through polkit,
but is limited to auth_admin:
<action id="org.freedesktop.login1.set-wall-message">
<description gettext-domain="systemd">Set a wall message</description>
<message gettext-domain="systemd">Authentication is required to set a wall message</message>
<defaults>
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
</defaults>
</action>
Bug introduced in 9ef15026c0
('logind/systemctl: introduce SetWallMessage and --message', 2015-09-15).
In the documentation, using the term "managed" for both the RA flag and
the DHCPv6 mode is confusing because the mode is referred to as
"solicit" both in the official DHCPv6 documentation (see RFC 8415) and
in the WithoutRA option.
Furthermore, calling the other RA flag "other information" or "other
address configuration" is confusing because its official name is simply
"other configuration" (see RFC 4861 and RFC 5175) and it isn't used to
assign IP addresses.
Rewrite the documentation for DHCPv6Client and WithoutRA to make it
clear that getting the "managed" RA flag triggers the same kind of DHCP
request as WithoutRA=solicit, whereas getting the "other configuration"
RA flag triggers the same kind of DHCP request as
WithoutRA=information-request.
Plain strv_split() should not care if the strings contains backslashes
or quote characters. But extract_first_word() interprets backslashes
unless EXTRACT_RETAIN_ESCAPE is given.
I wonder how it's possible that nobody noticed this before. I think this
code was introduced in 0645b83a40.
Fixup for a5efbf468c: if $COLORTERM was set, we'd
unconditionally turn on colors, which is unexpected and wrong. It even breaks
our own tests when executed in gnome-terminal.
This reverts commit d6c9411072.
I still think this is something that needs to be done, but we're hitting some
unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920.
So let's revert this for now, so -rc2 can be released, with a plan to return
to this after a release.
Closes#22920.
With a recent change paths leaving the statically known lookup paths would be
treated differently then those that remained within those. That was done
(AFAIK) to consistently handle alias names. Unfortunately that means that on
some distributions, especially those where /etc/ consists mostly of symlinks,
would trigger that new detection for every single unit in /etc/systemd/system.
The reason for that is that the units directory itself is already a symlink.
Rebased-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
The LLDP spec (IEEE 802.1AB) requires the three mandatory TLVs (Chassis
ID, Port ID, and TTL) to be the first three TLVs in the packet, in that
specific order, whereas systemd put the TTL near the end of the packet.
This violation caused the ethernet switch in our office to discard these
packets as malformed, and Wireshark's packet parser also chokes on them.
```
timedatectl list-timezones --no-pager
...
==164329==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8192 byte(s) in 1 object(s) allocated from:
#0 0x7fe8a74b6f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
#1 0x7fe8a63485dc in strv_push ../src/basic/strv.c:419
#2 0x7fe8a6349419 in strv_consume ../src/basic/strv.c:490
#3 0x7fe8a634958d in strv_extend ../src/basic/strv.c:542
#4 0x7fe8a643d787 in bus_message_read_strv_extend ../src/libsystemd/sd-bus/bus-message.c:5606
#5 0x7fe8a643db9d in sd_bus_message_read_strv ../src/libsystemd/sd-bus/bus-message.c:5628
#6 0x4085fb in list_timezones ../src/timedate/timedatectl.c:314
#7 0x7fe8a61ef3e1 in dispatch_verb ../src/shared/verbs.c:103
#8 0x410f91 in timedatectl_main ../src/timedate/timedatectl.c:1025
#9 0x41111c in run ../src/timedate/timedatectl.c:1043
#10 0x411242 in main ../src/timedate/timedatectl.c:1046
#11 0x7fe8a489df1f in __libc_start_call_main (/lib64/libc.so.6+0x40f1f)
```
