----- Original Message -----
> Well ... I am assuming that the order of importance is ...
>
> 1. PCP works
> 2. non-root execution is goodness
> 3. lintian compliance
>
*nod*.
> So I think there is no option other than finding a way to smack
> lintian.
I'll take a look, lets assume I can "make it so" for now though.
> I battled for 6 hours trying to figure out why qa/255 was failing,
Ouch. :|
> and I
> would be very surprised to find an alternative solution that does not
> involve making the mode for $PCP_LOG_DIR/pmcd more permissive.
We need to be super careful then with tmpfile issues. I suspect for
example that this opens a symlink attack vector via __pmOpenLog() -
its current use of unlink + freopen/fdreopen with no O_EXCL looks
problematic (needs "x" flag on glibc? or reimplement). Fortunately
all PCP uses will be accessing the logdir through that one routine.
> If it is not 1777, then I suspect it could possibly be 755 and _owned_
> by the user pcp ... I changed it by hand post-install to be thus and
> pmcd starts (with a bunch of root owned log files therein) and qa/255
> passes. Would that be any less sucky for lintian and any of the
> other packaging pixies?
Isn't that what the packaging does though? debian/pcp.postinst has
chown -R pcp:pcp /var/log/pcp/pmcd 2>/dev/null || true
How did it become root:root again?
> I cannot test on fedora/suse/centos as I am still stuck there with
> the python rpm packaging failures I mentioned on 26 Nov.
>
Hmmm, Fedora and RHEL builds are OK for me, and I'd missed that there
were still issues there. Only python issues I knew of were on Debian
(which we'd mostly fixed, except for the lintian issue) and the RHEL4
report from Chandana.
I'll go take a peek, thanks.
cheers.
--
Nathan
|