Bug 1223311

| According to these /usr/sbin/rndc tries to open /var/lib/pcp/pmdas/named/domain.h.perl and /var/lib/pcp/pmdas/named/pmns.perl

This is so strange - the way that these two files (pmns & domain.h .perl files) come into being is the pmdas/named/Install script creates them, via shell code in $PCP_SHARE_DIR/lib/pmdaproc.sh

pmdaproc.sh uses special environment variables to trigger code in PMDA.run(), called by pmdanamed.pl to generate a namespace and domain.h file - in normal operation (i.e. any time pmdanamed.pl might be invoking rdnc) these files should *not* be getting created ... so, wow, I'm surprised this is happening!

Will need some deeper investigation I think.  In the meantime, for this kind of bug Miloš (i.e. where the "Steps to reproduce" ends with a PMDA ./Install) it would be very helpful to create an upstream pcp qa/NNN test.  The qa/755 test for the Apache PMDA would be a good example to follow - if we begin producing these, then upstream community developers like kenj will start helping us to fix 'em more quickly, which would be an awesome outcome for RHEL.  :)

(In reply to Nathan Scott from comment #1)
> | According to these /usr/sbin/rndc tries to open
> /var/lib/pcp/pmdas/named/domain.h.perl and /var/lib/pcp/pmdas/named/pmns.perl

Ah, as I read it again, this is not the correct interpretation of those two AVC denials, I'm sorry for that, it's definitely misleading. Selinux is complaining about rndc trying to *write* into those files, not about opening them. As I mentioned, files may have been opened by parent process, and leaked into rndc process somewhere later, not being properly closed before forking rndc.

> 
> This is so strange - the way that these two files (pmns & domain.h .perl
> files) come into being is the pmdas/named/Install script creates them, via
> shell code in $PCP_SHARE_DIR/lib/pmdaproc.sh
> 
> pmdaproc.sh uses special environment variables to trigger code in
> PMDA.run(), called by pmdanamed.pl to generate a namespace and domain.h file
> - in normal operation (i.e. any time pmdanamed.pl might be invoking rdnc)
> these files should *not* be getting created ... so, wow, I'm surprised this
> is happening!
> 
> Will need some deeper investigation I think.

For this, I can provide you with few boxes from beaker pool. This issue is quite easy to reproduce, I noticed in several different test runs I started during the last week.

> In the meantime, for this kind
> of bug Miloš (i.e. where the "Steps to reproduce" ends with a PMDA
> ./Install) it would be very helpful to create an upstream pcp qa/NNN test. 
> The qa/755 test for the Apache PMDA would be a good example to follow - if
> we begin producing these, then upstream community developers like kenj will
> start helping us to fix 'em more quickly, which would be an awesome outcome
> for RHEL.  :)

Sounds good! I'll contact you on irc/by mail before I start spamming pcp with qe patches :)

Hi Miloš,

I think I understand what's happening here now.  Not an urgent fix (the Install process still works even though these AVC denials a being generated), but could you try out the patch below when next opportunity available?  (needs a system with rndc setup).

diff --git a/src/pmdas/named/pmdanamed.pl b/src/pmdas/named/pmdanamed.pl
index a0f03ba..a005d66 100644
--- a/src/pmdas/named/pmdanamed.pl
+++ b/src/pmdas/named/pmdanamed.pl
@@ -120,6 +120,16 @@ foreach $statsdir ( @paths ) {
     last if ( -f $statsfile );
 }
 die "Cannot find a valid named statistics file\n" unless -f $statsfile;
+
+# Perform the namespace and domain evaluation earlier than usual.
+# This must be done to ensure we do not execute "rndc stats" with
+# our stdout set to either of these locations (SElinux AVC denial
+# results otherwise).
+if (defined($ENV{PCP_PERL_PMNS}) || defined($ENV{PCP_PERL_DOMAIN})) {
+    $pmda->run;
+    exit(0);
+}
+
 named_update();		# push some values into the statistics file
 
 $pmda->set_fetch_callback(\&named_fetch_callback);

Thanks for access Miloš, I've pushed a fix (and tests qa/1033,1034) upstream.

At this stage I'm thinking this ones probably not critical enough to warrant a backport, but if we pick up other fixes for 6.8 we could add this one in too.

cheers.

Verified for build pcp-3.10.9-6.el6.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0825.html