file descriptor passing in D-Bus: how much is actually used?

[Simon McVittie]

On 08/10/14 15:47, Colin Walters wrote:
> Unrelated to the actual numbers, one thing I have seen from a lot of
> field reports is sudden failures when people hit limits.

Yes, it would be good if dbus-daemon logged warnings to its standard log
destination (normally syslog for the system bus or stderr for the
session bus) whenever exceeding a limit has a destructive action. Some
limits just cause reading to be throttled, and should probably not log,
but most limits have some sort of destructive result (dropping messages
or disconnecting connections) and should log.

I'd happily review patches.

Alternatively, if I worked on doing this, would other D-Bus developers
review it / my various patches that are already pending in Bugzilla?
(Look for tag 'patch' and/or status whiteboard 'review?'.)

> Things like
> appending strings dynamically as message arguments, rather than as a
> single argument of "as".
>
> The former works until you hit 255 of them, then it explodes in your
> face...

I believe the story we've always had is that it is programming error to
construct a malformed message, and that D-Bus bindings should not be
trying to send the malformed message and hoping for the best (which is
why we considered it to be a bug that libdbus could try to send
non-UTF-8 in strings, or values >= 2 in booleans, and made it warn on
stderr and fail the API call instead).

However, if dbus-daemon is responding to a message validity failure by
kicking the peer off the bus, yes it should syslog something first.

I'm also tempted to suggest that we should be less draconian about
malformed message header fields or bodies, as long as the first 16 bytes
are comprehensible: those first 16 bytes are enough to work out how many
bytes we should skip before we start reading messages again (length of
header fields + align to multiple of 8 bytes + length of body), whether
we can consider sending an error reply (message type and
NO_REPLY_EXPECTED flag), and what to put in the error reply if any
(serial number).

Unfortunately, responding to message parse failures with an error is
non-trivial because of the way DBusConnection is layered, and because we
try to deal with malloc() returning NULL. In particular, if it fails
with out-of-memory, we basically just have to drop the message on the
floor and forget about it.

    S