bus: Try to raise soft fd limit to match hard limit
authorSimon McVittie <smcv@collabora.com>
Mon, 11 Mar 2019 09:03:39 +0000 (09:03 +0000)
committerSimon McVittie <smcv@collabora.com>
Mon, 13 May 2019 10:50:34 +0000 (11:50 +0100)
commit94bacc6955e563a7e698e53151a75323279a9f45
treeb0eaa4a967c5021bbbb206eecba1fee2dcd2adce
parent6e432ed51e8f9ff62d935a0a568385144d97afbf
bus: Try to raise soft fd limit to match hard limit

Linux systems have traditionally set the soft limit to 1024 and the hard
limit to 4096. Recent versions of systemd keep the soft fd limit at
1024 to avoid breaking programs that still use select(), but raise the
hard limit to 512*1024, while in recent Debian versions a complicated
interaction between components gives a soft limit of 1024 and a hard
limit of 1024*1024. If we can, we might as well elevate our soft limit
to match the hard limit, minimizing the chance that we will run out of
file descriptor slots.

Unlike the previous code to raise the hard and soft limits to at least
65536, we do this even if we don't have privileges: privileges are
unnecessary to raise the soft limit up to the hard limit.

If we *do* have privileges, we also continue to raise the hard and soft
limits to at least 65536 if they weren't already that high, making
it harder to carry out a denial of service attack on the system bus on
systems that use the traditional limit (CVE-2014-7824).

As was previously the case on the system bus, we'll drop the limits back
to our initial limits before we execute a subprocess for traditional
(non-systemd) activation, if enabled.

systemd activation doesn't involve us starting subprocesses at all,
so in both cases activated services will still inherit the same limits
they did previously.

This change also fixes a bug when the hard limit is very large but
the soft limit is not, for example seen as a regression when upgrading
to systemd >= 240 (Debian #928877). In such environments, dbus-daemon
would previously have changed its fd limit to 64K soft/64K hard. Because
this hard limit is less than its original hard limit, it was unable to
restore its original hard limit as intended when carrying out traditional
activation, leaving activated subprocesses with unintended limits (while
logging a warning).

Reviewed-by: Lennart Poettering <lennart@poettering.net>
[smcv: Correct a comment based on Lennart's review, reword commit message]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7eacbfece70f16bb54d0f3ac51f87ae398759ef5)
[smcv: Mention that this also fixes Debian #928877]
bus/bus.c
dbus/dbus-sysdeps-util-unix.c
dbus/dbus-sysdeps-util-win.c
dbus/dbus-sysdeps.h