method timeouts vs systemd activation and slow systems

[Simon McVittie]

On Fri, 17 Mar 2023 at 10:30:20 -0400, Colin Walters wrote:
> 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

I would hope that those virtual ISOs, being virtual, are considerably
faster than the CD drives that early Ubuntu was intended to be able to
run from.

> > 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.

dbus-daemon combines per-connection resource limits with a limit on
connections per uid, which is indirectly a limit on resources per uid.
The choice of whether to have a tighter limit on resources per connection
than resources per uid is a trade-off, and neither approach is necessarily
better than the other in all situations.

dbus-daemon's model with a per-connection limit protects against accidents
as well as malice: one process owned by uid 1000 can't accidentally use up
all of the quota allowed for uid 1000, and cause other processes to fail.
Each client can only hurt itself, not other clients, unless there are
so many clients that the limit on connections per uid is exhausted.

If dbus-broker only has a per-uid limit, that has the disadvantage
that it does not protect against accidents in that way, but in return,
it has the advantage that in practice it will usually allow a small
number of "important" connections to use a lot of resources if they
need to (whereas dbus-daemon can't allow that, in order to cope with
the worst-case scenario where a large number of connections all reach
their individual resource limits).

    smcv