[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: Proper handling of the dbus call method timeout
From:       Anton Gorenkov <anton.gorenkov.ua () gmail ! com>
Date:       2023-06-08 11:57:32
Message-ID: CAGMAZpPrddomd9YGPc63PDLzHj6vjug2y1Dz++t+2yp1VdMi+w () mail ! gmail ! com
[Download RAW message or body]

Thank you for the quick reply, Simon!

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. Can this approach work
in general? Is it a dirty hack or can it be considered as an
acceptable workaround?

Thanks,
Anton.

On Wed, 07 Jun 2023 at 21:44, Simon McVittie <smcv@collabora.com>:
>
> 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
[prev in list] [next in list] [prev in thread] [next in thread]