pcp
[Top] [All Lists]

Re: [pcp] [Bug 981] pmlc security

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] [Bug 981] pmlc security
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Sun, 14 Jul 2013 16:09:05 +1000
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <bug-981-835-G8g8m8aMcK@xxxxxxxxxxxxxxxx/bugzilla/>
References: <bug-981-835@xxxxxxxxxxxxxxxx/bugzilla/> <bug-981-835-G8g8m8aMcK@xxxxxxxxxxxxxxxx/bugzilla/>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
On 13/07/13 08:32, bugzilla-daemon@xxxxxxxxxxx wrote:
...
OK.  (Have you considered perhaps going through pmcd to talk to a pmlogger?
That way we get networking & security.)

I am hesitant to add load to pmcd especially as it does not (currently) have an another thread it could use to have a chat to pmlogger.

But the biggest problem here is that on many installations I've worked with, there is _no_ pmcd running where all the pmlogger action takes place, i.e. a true pmlogger farm. All the pmlogger_foo scripts are independent of pmcd running on the localhost.

I do understand this does not match the common use case RH may be envisaging.

There is already an access control clause available in the pmlogger
configuration files, and I think Nathan's recent work on making a better
fist of creating default pmlogger configuration files included turning off
remote pmlc access to change the pmlogger config (stops my 2. above, but
allows 1.).

For what it's worth, even unauthenticated localhost access does not fare
much better from a security point-of-view.

But we could also make the default setup in the absence of humanoid intervention to stop access from any host (including localhost) that would modify the pmlogger state.

Except that the data stored by pmlogger can be manipulated by unauthorized
pmlc usage (whereas pmcd is on the whole read-only), so that makes the
pmlogger archives unreliable as a record of what happened.

Fair point.

<Prev in Thread] Current Thread [Next in Thread>