Description of problem: SELinux is preventing /usr/bin/bash from 'read' accesses on the directory /var/lib/pcp/pmdas. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that bash should be allowed read access on the pmdas directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep pmcd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:pcp_var_lib_t:s0 Target Objects /var/lib/pcp/pmdas [ dir ] Source pmcd Source Path /usr/bin/bash Port <Unknown> Host (removed) Source RPM Packages bash-4.3.42-4.fc24.x86_64 Target RPM Packages pcp-3.11.0-1.fc24.x86_64 Policy RPM selinux-policy-3.13.1-176.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.5.0-0.rc7.git0.2.fc24.x86_64 #1 SMP Tue Mar 8 02:20:08 UTC 2016 x86_64 x86_64 Alert Count 60 First Seen 2016-02-22 11:29:31 EST Last Seen 2016-03-14 08:43:23 EDT Local ID 35195f33-93de-43f0-89f8-566caa9cbad1 Raw Audit Messages type=AVC msg=audit(1457959403.535:204): avc: denied { read } for pid=2352 comm="pmcd" name="pmdas" dev="dm-1" ino=924113 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:pcp_var_lib_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1457959403.535:204): arch=x86_64 syscall=open success=no exit=EACCES a0=56110517a3cb a1=90800 a2=7fa92f58cb58 a3=1e0 items=0 ppid=1 pid=2352 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=pmcd exe=/usr/bin/bash subj=system_u:system_r:init_t:s0 key=(null) Hash: pmcd,init_t,pcp_var_lib_t,dir,read Version-Release number of selected component: selinux-policy-3.13.1-176.fc24.noarch Additional info: reporter: libreport-2.6.4 hashmarkername: setroubleshoot kernel: 4.5.0-0.rc7.git0.2.fc24.x86_64 type: libreport
Hi, How did you start pmcd? pcmd daemon should run as pcp_pmcd_t.
I assume it started via systemd unit, because I didn't do anything specific with it. I'm pretty sure it's on my system because at some point I installed cockpit-pcp and that came with it.
*** Bug 1398146 has been marked as a duplicate of this bug. ***
Stephen, You are right, it'c caused by cockpit when you turn on storing performance data. After discussing issue with mvollmer on IRC, pcp run some deamons directly, which can be problem from SELixnu POV.
(In reply to Lukas Vrabec from comment #4) > Stephen, > You are right, it'c caused by cockpit when you turn on storing performance > data. > > After discussing issue with mvollmer on IRC, pcp run some deamons directly, > which can be problem from SELixnu POV. And "running directly" means that there seems to be a cron job that runs /usr/share/pcp/lib/pmlogger start Instead, I think the cron job should run "systemctl start pmlogger". See https://bugzilla.redhat.com/show_bug.cgi?id=1185764 If pcp considers /usr/share/pcp/lib/pmlogger to be API that it wants to keep, then I'd say that on platforms with systemd, /usr/share/pcp/lib/pmlogger should redirect to systemctl, instead of the systemd unit calling /usr/share/pcp/lib/pmlogger.
There's some confusion here I think - certainly I'm confused :P - the initial bug report is about the pmcd daemon, but comments #4 and #5 are about pmlogger which is a completely different kettle of fish. The startup processes are quite different, and there is no relationship between cron and pmcd. AFAICT, this looks more like a selinux-policy issue than a PCP problem... happy to be educated though, and happy to help fix it either way. Something else that's not clear to me, is in the log message: comm="pmcd" name="pmdas" dev="dm-1" ... I presume 'comm' is the basename of the pmcd command, but what are 'name' and 'dev' in this context? (based on my fairly intimate knowledge of the pmcd code, its not clear to me where/how pmcd would access either a "pmdas" or "dm-1" entity itself, usually that would be a PMDA process like pmdalinux. Thanks!
> (based on my fairly intimate knowledge of the pmcd code, its not clear to me > where/how pmcd would access either a "pmdas" or "dm-1" entity itself, usually > that would be a PMDA process like pmdalinux. Thanks! pmdalinux used to be a DSO by default; 3.10.2 changed it. Perhaps they are running even an older version or using a non-default configuration.
(In reply to Frank Ch. Eigler from comment #7) > pmdalinux used to be a DSO by default; 3.10.2 changed it. Perhaps they are > running even an older version or using a non-default configuration. From comment #1 in the bug report: Target RPM Packages pcp-3.11.0-1.fc24.x86_64 And a non-default pmcd.conf Linux PMDA entry is of course extremely unlikely (esp. as we do not ship PMDA Install files for pmdalinux). We can check it; Stephen if you could attach your /etc/pcp/pmcd/pmcd.conf file to this BZ? My earlier questions remain for the SElinux folk, anyway.
Just noticed Stephens comment in #c3 too - "I didn't do anything specific with it." - so all of #c7 is not relevant here. Assigning back to selinux-policy as per #c6 - there appears to be no PCP issue here and no response to my earlier questions. I'm still very happy to help and / or advise from a PCP POV if needed, of course, just let me know.
Description of problem: Installed pcm enabled pcmd service and started. This message appeared after the next boot. Version-Release number of selected component: selinux-policy-3.13.1-225.6.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.16-300.fc25.x86_64 type: libreport
pcp-3.12.0-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d29400ff30
pcp-3.12.0-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9103ca28d1
pcp-3.12.0-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d29400ff30
pcp-3.12.0-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9103ca28d1
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
pcp-3.12.0-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.12.0-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.