The kernel provides %d which is documented as
"dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE".
We already query /proc/pid/auxv for this information, but unfortunately this
check is subject to a race, because the crashed process may be replaced by an
attacker before we read this data, for example replacing a SUID process that
was killed by a signal with another process that is not SUID, tricking us into
making the coredump of the original process readable by the attacker.
With this patch, we effectively add one more check to the list of conditions
that need be satisfied if we are to make the coredump accessible to the user.
Reportedy-by: Qualys Security Advisory <qsa@qualys.com>
In principle, %d might return a value other than 0, 1, or 2 in the future.
Thus, we accept those, but emit a notice.
No functional change. This change is done in preparation for future changes.
Currently, the list of fields which are received on the command line is a
strict subset of the fields which are always expected to be received on a
socket. But when we add new kernel args in the future, we'll have two
non-overlapping sets and this approach will not work. Get rid of the variable
and enumerate the required fields. This set will never change, so this is
actually more maintainable.
The message with the hint where to add new fields is switched with
_META_ARGV_MAX. The new order is more correct.
This breaks GNOME on Wayland, login no longer works:
gnome-shell[2250]: Running GNOME Shell (using mutter 48.2) as a Wayland display server
gnome-shell[2250]: Failed to setup: Failed to find any matching session
systemd[2054]: org.gnome.Shell@wayland.service: Failed with result 'protocol'.
systemd[2054]: Failed to start org.gnome.Shell@wayland.service - GNOME Shell on Wayland.
This reverts commit b0555149de.
test_keep_configuration_on_restart() works, but the error printed is
misleading because self.assertNotEmpty() doesn't exist.
Add a working assert statement so, when the unmanaged interface is
altered, the test fails with a meaningful error, like:
### ip monitor dev unmanaged0 BEGIN
222:33::/64 proto kernel metric 256 pref medium
FAIL
[...]
Traceback (most recent call last):
File "/work/src/test/test-network/systemd-networkd-tests.py", line 5085, in test_keep_configuration_on_restart
self.assertEqual(line, '')
AssertionError: '222:33::/64 proto kernel metric 256 pref medium' != ''
- 222:33::/64 proto kernel metric 256 pref medium
While at it, strip the trailing newline so we can print easily the
string (and in future build more a robust regexp which uses the $ token)
This was broken in f45b801551. Unfortunately
the review does not talk about backward compatibility at all. There are
two places where it matters:
- During upgrades, the replacement of kernel.core_pattern is asynchronous.
For example, during rpm upgrades, it would be updated a post-transaction
file trigger. In other scenarios, the update might only happen after
reboot. We have a potentially long window where the old pattern is in
place. We need to capture coredumps during upgrades too.
- With --backtrace. The interface of --backtrace, in hindsight, is not
great. But there are users of --backtrace which were written to use
a specific set of arguments, and we can't just break compatiblity.
One example is systemd-coredump-python, but there are also reports of
users using --backtrace to generate coredump logs.
Thus, we require the original set of args, and will use the additional args if
found.
A test is added to verify that --backtrace works with and without the optional
args.
We generally frown on config options that are called
EnableXYZ=/DisableXYZ=, hence drop this here too. Note that the original
sin was that the pre-existing D-Bus property already used the prefix.
But given that D-Bus properties are substantially more low-level (i.e.
developer focused) than the config knobs, let's bite the bullet and
name the configuration option cleanly, even if the dbus property carries
the damn prefix.
The knob was added post v257, hence this is not a compat break.
Follow-up for: 130698dc20
We need to protect us from recycled PIDs here like everywhere else: once
we read data from /proc/$PID/ we need to validate that $PID still points
to the original pidfd.
parse_env_file() applies a certain kind of unescaping, and we really
need to match that when writing out arbitrary strings.
(This gets a bit confusing in the inhibit case, since that already
applied one level of escaping on its own...)
This replaces use of fopen_temporary() with fopen_tmpfile_linkable() +
flink_tmpfile(). This both shortens the code and means we use O_TMPFILE
for installing these files, which is always good.
No change in behaviour otherwise.