method timeouts vs systemd activation and slow systems

[Colin Walters]

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.