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

List:       freedesktop-dbus
Subject:    Re: method timeouts vs systemd activation and slow systems
From:       "Colin Walters" <walters () verbum ! org>
Date:       2023-03-17 14:30:20
Message-ID: 80b28411-c212-4734-bcbe-f8465559d19e () betaapp ! fastmail ! com
[Download RAW message or body]



On Mon, Mar 6, 2023, at 7:39 AM, Simon McVittie wrote:
> could still work live CDs, back when those were a thing.

Ah but see, those are definitely still a thing on some bare metal servers =)
Basically there's an "iLO" or management layer can support attaching "virtual" ISOs
https://support.hpe.com/hpesc/public/docDisplay?docId=a00045843en_us&docLocale=en_US
And this is very much actively used.

> Some of these limits are security-sensitive, in that they are used as
> an anti-denial-of-service mechanism to prevent a malicious client from
> tying up finite message bus resources indefinitely (we probably cannot
> ever fully prevent denial of service via resource exhaustion, but these
> limits mitigate it).

In most realistic scenarios where dbus is deployed, a malicious client can call \
fork(). Anything that's per-client is not very useful.  I think this is the rationale \
behind  https://github.com/bus1/dbus-broker/wiki/Accounting doing things per-uid.  \
(But ultimately it'd be better to tie into cgroups in some way)

> To be clear, are you proposing that the message bus implementations
> should have a configuration option that doesn't actually do anything
> within the message bus itself, but is passed on to their clients as a
> suggestion "this would be a good default for you to use"?

Right.

> As others have said already, there would be a bit of a chicken-and-egg
> problem with using a DBus method call to retrieve this limit, but it
> would be easy for client libraries to special-case the initial method
> calls to have a long or infinite timeout. Pseudocode:
> 
> C: <SASL stuff>
> S: <SASL stuff>
> C: BEGIN
> C: o.fd.DBus.Hello (with long or infinite timeout)
> S: reply to o.fd.DBus.Hello with the unique name
> C: o.fd.DBus.GetAll(o.fd.DBus) (with long or infinite timeout)
> S: {Features: <[...]>, Interfaces: <[...]>, SuggestedTimeout: <42000>}
> C: (continue with its real work, with default timeout = 42000ms)
> 
> The client could easily pipeline the Hello and GetAll messages, if desired:
> that's going to be a lot more reliable than pipelining the SASL handshake,
> because "normal D-Bus" is more expressive than the SASL handshake, and has
> a better framing protocol.

Yeah, this one sounds good to me.


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