pcp
[Top] [All Lists]

Re: pcp files/dirs in /etc not owned by root

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: pcp files/dirs in /etc not owned by root
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 25 Sep 2014 10:07:54 +1000
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0mh9zwr3s9.fsf@xxxxxxxx>
References: <54234B15.1050901@xxxxxxxxxxxxxxxx> <y0mh9zwr3s9.fsf@xxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
On 25/09/14 09:34, Frank Ch. Eigler wrote:
...
On my machine, this is:

% ls -al /etc/pcp/pmcd/pmcd.conf /etc/pcp/pmcd/pmcd.options
-rw-r--r--. 1 root  pcpqa 770 Apr 23 21:26 /etc/pcp/pmcd/pmcd.conf
-rw-r--r--. 1 pcpqa pcpqa 606 Apr  7 21:58 /etc/pcp/pmcd/pmcd.options

It indicates that running the pcpqa suite leaves stains, as it were,
on the well-bleached defaults that come with the base package.  (I've
long dreamed of a pcpqa implementation that leaves the /etc/pcp/*
files and system daemons well alone, and runs private copies on
alternate ports etc. only.)

qa/944 is the test that is supposed to catch these cases, but it is only looking for the ones that "should" be non-root owned (not just below /etc but in other "ok" places). We could/should extend that test to check for not owned by root below /etc/pcp ... after I've fixed the code and packaging.

Disciplined writing of QA scripts will fix this issue ... the pmcd.options one is real easy, for example. On the other hand scripts making changes to pmcd.conf are a little more omnipresent ... 8^)>

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