Hi -
> > > [...] I'll make the needed pmwebd changes this week.
> >
> > The local:* stuff should not be marked as deprecated nor
> > be undocumented: that still has plenty of safe & appropriate use.
>
> If pmwebd acquires some form of explicit ACL, maybe (where people
> will still have to opt-in to exposing information) - until then no,
> there's no point risking that unnecessarily.
"unnecessarily" is in the eye of the beholder/user. The "-P" is an
opt-in. In another thread elsewhere we have already covered a
reasonable use case where pmwebd could run as root & expose local:,
for a single highly-privileged application.
> > "pmcd now only hangs for a few seconds after a hostile client
> > sends a few bytes of data instead of indefinitely" in code:
>
> Yep, interesting, thanks - so not nearly as bad as those initial
> arbitrarily broad "pmcd DoS" claims.
To spell it out further ... When you are on a hostile network, you
will get not one bad guy sending those few bytes once in a while but
hundreds concurrently, and pmcd will effectively stop.
> In normal operation pmcd can be delayed for such short times under
> heavy local load anyway. I don't think it's a realistic security
> concern in the bigger picture of uses of the service that pmcd is
> offering
OK, so now you grant my point that pmcd shouldn't be put onto a
hostile network.
> - but if its worrying you, please have at it.
You weaponized the whole issue, after I presumed to question the
wisdom & safety of building more upon pmStore, a design that still has
a number of outstanding questions/problems. We could have hammered
those out instead of this distraction.
- FChE
|