Proper handling of the dbus call method timeout

[Simon McVittie]

On Thu, 08 Jun 2023 at 14:57:32 +0300, Anton Gorenkov wrote:
> I also tried the solution when the client generates a reply to its
> method call by itself for dbus-daemon after timeout is reached. Still,
> this didn't work, but maybe I missed something.

That can't work. When the dbus-daemon tracks whether a method call has had
a reply, it does that on the basis of (sender, serial number, recipient)
tuples, where the sender and recipient are connection objects inside the
dbus-daemon (if you look at the unique names like :1.23 in dbus-monitor,
those have a 1:1 relationship with connection objects). Sending a reply
to the same serial number, but from a different sender, does nothing.

If that didn't happen, it would be possible for a malicious client
to forge replies to someone else's method calls. Also, in practice
D-Bus clients usually start by sending serial number 1 and increment
from there, so the serial numbers from each client are often going to
be small numbers that are unintentionally equal, and that needs to be
something that won't cause a problem.

I can only see two ways to make this work, other than fixing the service,
and both would require changes in the dbus-daemon:

* defining a new optional message header that tells the dbus-daemon
  "if this isn't delivered before *n* seconds have passed, you can forget
  it" (with a value slightly larger than the client-side timeout), so that
  the dbus-daemon can use that header to start timing out messages again;

* changing what happens when the maximum number of pending replies is
  reached, so that instead of making the *newest* calls from the same
  client fail, the dbus-daemon would make the *oldest* calls for the same
  client (or maybe the same (client,service) pair) report a NoReply or
  LimitsExceeded failure message synthesized by the dbus-daemon

If you want to work on implementing one of those, please open an issue
and I'd be happy to review merge requests as time permits. They are
unlikely to happen unless someone volunteers to implement them.

I have not thought about this very much, and it's entirely possible that
one or the other of those suggestions is unworkable, would introduce
a denial-of-service vulnerability, or is possible but surprisingly
difficult to achieve. We can't really tell until someone has a more
concrete proposal.

    smcv