Here SYNTHETIC_ERRNO() was used based on the general rule that logging
functions should do that when the error value is generated at the call
site. But here we're really propagating a memory allocation error, which
wasn't reported using errno, but the meaning is the same. And it's better
to bend the rule a bit like this than to use strerror().
strerror() is not thread safe and calling it just isn't worth the effort
required to justify why it would be safe in those cases. It's easier to just
use %m which is thread-safe out of the box. I don't think that any of the
changes in the patch cause any functional difference. This is just about
getting rid of calls to strerror() in general.
When we print an error message and fail to format the string, using something
like "(null)" is good enough. This is very very unlikely to happen anyway.
Error handling in acquire_user_record() was checking the wrong
condition (PAM errors are always >= 0, so r < 0 cannot match).
Apart from the fix for error handling, no change in behaviour is intended.
I did some minor adjustements to formatting and added _cleanup_ in one more
place.
This is a primitive helper that wraps calls to pam_syslog() replacing
@PAMERR@ with pam_strerror() output in the format string. This allows for
a bunch of boilerplate to be removed.
@PAMERR@ is only supported at the end of the string. Similarly to %m,
realistically that's the only place where it is useful.
Note that unlike in logging functions in log.[ch], here the error value is
only used for the message and is not saved anywhere, so we don't need to
care about SYNTHETIC_ERRNO.
So far our pam code was using strerror_safe(). But that's not a good approach,
because strerror_safe() is not thread-safe, and the pam code is "library code"
that should be thread-safe. In fact, the whole effort to use strerror() is
unnecessary, because pam_syslog() is documented to support %m. The
implementation in linux-pam simply uses vasprintf(). If we use %m too, we get
rid of the issue. The wrapper sets errno temporarily from the argument.
Apparently some PAM consumers run multiple PAM stacks in threads, so we should
avoid non-thread-safe code.
The new helper returns PAM_BUF_ERR for ENOMEM, and PAM_SERVICE_ERR in other
cases. This may change the returned code in some cases, but I think a) it
doesn't matter much, b) it's probably for the better. E.g. we might now return
PAM_SERVICE_ERR if the dbus message is borked, and PAM_SERVICE_ERR seems
appropriate.
In general, log_syntax_internal() must keep errno unchanged. But the
call to log_syntax_callback() was added outside of the block protected
by PROTECT_ERRNO.
If the lifetime of the route is already expired, do not try to
configure it.
Fixes a use-after-free, as the Request object is already freed, thus, we
cannot use Route or Link stored in Request object.
IPv6 Neighbor Discovery lets us autoconfigure a link's IPv6 addresses,
routes, DNS servers, and DNS search domains by listening for Router
Advertisement (RA) packets broadcast by one or more routers on the link.
Each RA can contain zero or more "options," each describing one piece of
configuration (e.g. a single route).
Currently, when we receive an RA from a router, we delete any addresses,
routes, etc. that originated from that router's previous RAs unless
they're also present as options in the new RA.
That behavior is a violation of RFC 4861[1]. In Section 9, the RFC
states that
Senders MAY send a subset of options in different packets. ... Thus,
a receiver MUST NOT associate any action with the absence of an
option in a particular packet. This protocol specifies that
receivers should only act on the expiration of timers and on the
information that is received in the packets.
Several other passages in the RFC reiterate this. Section 6.2.3:
A router MAY choose not to include some or all options when sending
unsolicited Router Advertisements.
Section 6.3.4:
Hosts accept the union of all received information; the receipt of a
Router Advertisement MUST NOT invalidate all information received in
a previous advertisement or from another source.
At least one consumer router in production today, the Google Nest Wifi,
often sends RAs that omit its global IPv6 prefix. When current versions
of systemd-networkd receive those RAs, they immediately delete the
interface's global IPv6 address, which breaks IPv6 connectivity.
Fix the issue by removing the invalidation logic entirely. It's not
needed at all, since we already invalidate addresses, routes, and DNS
configuration when the interface goes down or their lifetimes expire.
This fix does have the side effect of preventing changes to the .network
file (e.g. denylisted prefixes, whether to add routes from RAs) from
taking effect as soon as a new RA arrives. Instead, a full interface
reconfiguration is needed. But triggering those changes on RA receipt
was already rather arbitrary and out of the administrator's control, so
I think this change is fine.
commit 69203fba70 ("network: ndisc: remove old addresses and routes
after at least one SLAAC address becomes ready") introduced this
behavior. commit 50550722e3 fixed it partially, by preventing one
router's RAs from invalidating another router's configuration.
[1] https://www.rfc-editor.org/rfc/rfc4861
Fixes: 69203fba70 ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready")
The iscsi-init.service calls `sh` which might, in certain circumstances,
pull in instrumented systemd NSS modules causing `sh` to fail. Let's mitigate
this by pulling in an env file crafted by `create_asan_wrapper()` that
(among others) pre-loads ASan's DSO.
Add new key mappings for the HP Elite Dragonfly G2 laptop:
1. Map Fn+F12 (HP Programmable Key) to prog1.
2. Unmap Fn+F11 (Airplane mode) from atkbd and Intel HID events, as this
key is also reported by HP Wireless hotkeys.
The code to evaluate the kernel command line option was busted because it
was doing 'return b == !!r' at a point where 'r > 0'. Thus we'd return "true"
in both cases:
$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=true'
test.service: ConditionFirstBoot=true succeeded.
Conditions succeeded.
$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=false'
test.service: ConditionFirstBoot=false succeeded.
Conditions succeeded.
We only use 'ConditionFirstBoot=true' in units, so this wasn't noticed.
But I think the logic is broken in general: the condition should evaluate as
true only during initial boot. If we rerun the units at later points, we should
not consider ConditionFirstBoot to be true.
Also, the first boot logic is also used in pid1 itself. AFAICT, for two
things: in first boot machine-id is initialized transiently (this allows
first-boot operations to be restarted if boot fails), and preset-all is
executed. But this logic was different and separate from the logic to
evaluate ConditionFirstBoot. The distinction is abolished, and the operations
in pid1 now use the same logic as ConditionFirstBoot, which means that the
kernel command line option is checked, and condition_test_first_boot()
just tests whether pid1 thinks we're in first boot.
This makes things easier to grok for the user: there's just one condition for
"first boot" and it applies to both pid1 and units.
The text made it sound like breaking ABI in libsystemd is allowed with good reasons.
In fact, we plan never to do this, so make the language stronger.
Also remind people about distro forums for reporting bugs. Those are probably a
better place than systemd-devel for new users.
Also, add some missing articles and apostrophes, fix URLs, remove repeated phrases,
etc.
