Proper handling of the dbus call method timeout

[Simon McVittie]

On Wed, 07 Jun 2023 at 20:13:56 +0300, Anton Gorenkov wrote:
> Thus it looks like even
> though the timeout has been passed to libdbus and the reply error has
> been generated, dbus-daemon still tracks pending reply even after the
> timeout is reached.

Yes, the client-side timeout is purely internal to libdbus on the client
side, and the client does not tell the dbus-daemon what the timeout is
going to be.

The dbus-daemon must keep track of the pending replies because the
system bus security policy does not allow sending unrequested replies,
and it cannot store an unlimited number of them because if it did,
a malicious client/server pair could use that to make the dbus-daemon
use an unbounded amount of memory.

Very old dbus-daemon versions had their own arbitrary timeout after
which they would give up on a pending call and send back an error to the
caller, but this was removed from the default system bus configuration
a few years ago, because it effectively prevented clients from setting
a longer than usual timeout even if they wanted to.

> Is there a way to cancel pending call in the
> dbus-daemon queue? Alternatively, what is the supposed way to handle
> the case with missing replies on the client side (as the bug is
> actually on the method provider side, but method client is unable to
> perform bus calls after some tries)?

The only solution is to fix the service (method implementation). In
general, clients on the system bus need to trust the services that they're
calling methods on.

A workaround would be: if the service is irretrievably broken, terminate
the process. The dbus-daemon should detect the disconnection and forget
about its pending method calls, meaning they'll no longer count towards
the client's limit.

    smcv