On 21/02/14 07:18, Frank Ch. Eigler wrote:
... I
propose pmlogger also use that information to extend the pmlogger ACL
language to assert simple predicates like
allow unix-uidmatch : all;
# allow unix-gidmatch : all; # probably not a good default
allow unix : enquire;
which we could then put into the default / pmlogconf-generated files.
This looks fine to me.
As an aside, the pmlogger acl system has a nice separation of
"enquire" vs "all" operations. However, some mutative operations are
in the enquire category, but probably shouldn't be: namely "new
volume" and "flush". Both these could be misused for denial-of-service,
so should be restricted.
The status quo just seems wrong ... anything that can change the state
of pmlogger should not be in the "enquire" class. Shall I fix this?
Locking down pmlc is unlikely to have any negative fallout.
I believe pmlc use is very rare, probably because I have not managed to
convince anyone else that the "value add" proposition for pmlc in the
following scenario is real:
* pmlogger configured with shallow metric coverage and long sample intervals
* pmie looking for badness
<badness happens>
* pmie rule fires to ...
use pmlc to increase metric depth and/or reduce sample interval
wait a while
use pmlc to return pmlogger to default configuration
Even for this scenario, one could use a second pmlogger instance and
later merge the two archives with pmlogextract, avoiding pmlc altogether.
|