D-Bus daemon hits 100% CPU

[marcin at saepia.net]

Hello Simon

It is 1.10.6.  I use custom session bus. Really minimal config, just tcp,
anonymous auth (so far)  and default limits, no selinux.

My thoughts also went into direction of file descriptors limit. I increased
it already and I will observe if that behaviour appears again in the
upcoming days or weeks.

I cannot use Unix sockets as I use elixir and underlying erlang has no
proper Unix sockets support yet. I however plan to tunnel TCP over SSH
which should be secure enough for me.

I understand that Ford hack must have been an issue but I think disabling
ability to listen beyond localhost is a bad idea, as in some environments
it is exactly what is wanted. Redis server by default is also open and the
Web hasn't collapsed yet.

If you want to discourage using it, maybe call configuration key
"please-listen-on-all-ifaces-despite-this-being-bad-idea" but please do not
limit this.

M.
06.06.2016 1:38 PM "Simon McVittie" <simon.mcvittie at collabora.co.uk>
napisał(a):

> On 03/06/16 17:13, marcin at saepia.net wrote:
> > I've observed weird behaviour with reference D-Bus daemon (version from
> > ubuntu 16.04), it ocassionally hits 100% CPU.
>
> What exact version is this?
>
> On Debian derivatives like Ubuntu, if you are using the packaged
> dbus-daemon installed at /usr/bin/dbus-daemon, run "dpkg-query -W dbus".
>
> > It seem to happen when it
> > gets around 1000 client connections
>
> 1000 client connections sounds suspiciously similar to 1024, which is a
> common value for the RLIMIT_NOFILE limit that the kernel imposes on the
> dbus-daemon (RLIMIT_NOFILE, "Max open files" in /proc/${pid}/limits). We
> had issues a few years ago with the dbus-daemon's event loop going into
> a busy-loop when it tried to poll() RLIMIT_NOFILE file descriptors, but
> there are two reasons why we believe that should no longer apply:
>
> * that bug was caused by adding each file descriptor to the event loop
>   twice separately (for reading and writing), and we changed it to merge
>   the two watches into a single poll record (fixed in 1.5.6, bug
>   #23194);
> * we shouldn't be using poll() on modern Linux anyway, because I added
>   epoll support around the same time (1.5.10, bug #33337)
>
> I'd be interested in seeing stack traces and/or strace output from the
> busy-loop. Please open a bug. If you are using the packaged dbus-daemon
> from Ubuntu, install dbus-1-dbg before getting your stack traces, so
> that they'll contain useful information.
>
> > over TCP
>
> The TCP transport has the same security properties as 1980s-era NFS: it
> is only as secure as your network's ability to resist eavesdropping and
> spoofing, i.e. in practice it cannot be assumed to be secure. Please use
> the default AF_UNIX sockets instead. If you need remote D-Bus, I would
> recommend forwarding the normal AF_UNIX socket using a ssh tunnel or
> socat or similar.
>
> (One exception: on Windows, there is nothing better than TCP available
> to us, so it is OK to use the TCP transport listening on 127.0.0.1 or
> ::1; however, we do not consider dbus on Windows to be suitable for use
> at a security boundary.)
>
> This has been a serious real world problem: a dbus-daemon inadvisably
> configured to use the TCP transport was a key part of the 2015 Jeep hack
> that led to a recall of 1.4 million vehicles. We have seriously
> considered making dbus-daemon refuse to listen on TCP at all, except for
> 127.0.0.1 and ::1, to make it harder for dbus users to shoot themselves
> in the foot, and I might still do that for 1.12.
>
> > Is there anything particular in the config that could limit its capacity
> > regarding max clients limit?
>
> You haven't told me what configuration you are using, or whether this is
> the system bus, the session bus or a custom bus, so I can't say. If you
> are using TCP, then you are using a non-default configuration of some
> sort. What is that configuration?
>
> There are some hard-coded default limits used if the bus configuration
> (session.conf, system.conf, --config argument) does not specify a limit,
> but none of those are close to 1000: up to 2048 connections, of which
> each uid can have up to 256.
>
> --
> Simon McVittie
> Collabora Ltd. <http://www.collabora.com/>
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20160606/5992a617/attachment-0001.html>