[Pkg-utopia-maintainers] Bug#928877: dbus: some system services' fd limits not reset with systemd >= 240

[Simon McVittie]

Package: dbus
Version: 1.12.12-1
Severity: important
Tags: upstream fixed-upstream
Forwarded: https://gitlab.freedesktop.org/dbus/dbus/merge_requests/103

The system dbus-daemon currently sets its hard and soft RLIMIT_NOFILE
to 64K, with the intention of changing back to the rlimits with which
it was invoked when it carries out traditional system service activation
(without SystemdService). In stretch this worked fine, because dbus-daemon
was typically invoked with RLIMIT_NOFILE set to 1K (soft)/4K (hard), and
reducing limits from 64K/64K back to 1K/4K does not require privileges.

However, systemd since v240 invokes system services like dbus-daemon with
RLIMIT_NOFILE set to 1K (soft)/512K (hard)[1]. This means dbus-daemon, which
does not retain CAP_SYS_RESOURCE when it drops privileges, cannot restore
the original rlimit (because the hard limit in its original rlimit was
higher than the hard limit it is running with). This causes dbus-daemon to
log a warning and run system services with the same rlimits that
dbus-daemon itself has.

The result is that some system services are invoked with a
higher-than-intended soft limit (which might break buggy services that
assume they can select() on all fds below their soft limit, which were
the justification for systemd 240 keeping a relatively low soft limit),
and with a lower-than-intended hard limit (which might break services
that want to increase their soft limit so they can have lots of fds
open). It also results in dbus-daemon logging a warning for every
traditional activation, causing unnecessary noise in syslog.

This is already fixed in upstream git by a change that makes a privileged
dbus-daemon set its own hard and soft RLIMIT_NOFILE to
MIN(64K, its current hard limit) before dropping privileges, with the
result that dbus-daemon runs with RLIMIT_NOFILE set to 512K, and going
back to 1K (soft)/512K (hard) for traditional activation does not require
exercising CAP_SYS_RESOURCE. At the time I wrote that change I thought it
was an enhancement rather than a regression fix.

Now that I know this is a regression fix, I'm intending to release a
fixed version of dbus next week.

    smcv

[1] On some systems, such as my laptop, an interaction that I don't fully
    understand between systemd and pam_limits results in the hard
    limit being even higher: 1M instead of 512K. On those systems,
    every mention of 512K in this bug report becomes 1M, but everything
    else remains true.