Bug 501546
Summary: | Monitoring, selinux denial for snmp probe , "TSDBLocalQueue." | |||
---|---|---|---|---|
Product: | Red Hat Satellite 5 | Reporter: | wes hayutin <whayutin> | |
Component: | Monitoring | Assignee: | Jan Pazdziora <jpazdziora> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | wes hayutin <whayutin> | |
Severity: | medium | Docs Contact: | ||
Priority: | low | |||
Version: | 530 | CC: | cperry, msuchy, mzazrivec | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
URL: | https://grandprix.rhndev.redhat.com/rhn/systems/details/probes/ProbesList.do?sid=1000011096 | |||
Whiteboard: | ||||
Fixed In Version: | sat530 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 505012 (view as bug list) | Environment: | ||
Last Closed: | 2009-09-10 18:49:43 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 457079, 463877, 505012 |
Description
wes hayutin
2009-05-19 17:22:53 UTC
also get pid=4171 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=pts1 ses=2138 comm="TSDBLocalQueue." exe="/usr/bin/perl" subj=root:system_r:spacewalk_monitoring_t:s0 key=(null) Upon fresh install of Satellite-5.3.0-RHEL5-re20090528.0, the types are # ls -laZ /var/log/nocpulse/TSDBLocalQueue drwxr-xr-x apache apache system_u:object_r:var_log_t . drwxrwxr-x nocpulse apache system_u:object_r:spacewalk_monitoring_log_t .. drwxr-xr-x apache apache system_u:object_r:var_log_t archive drwxr-xr-x apache apache system_u:object_r:var_log_t failed drwxr-xr-x apache apache system_u:object_r:var_log_t queue in spite of the fact that /var/log/nocpulse/TSDBLocalQueue is owned by tsdb # rpm -qf /var/log/nocpulse/TSDBLocalQueue tsdb-1.27.19-2.el5sat and the type is properly defined: # grep /var/log/nocpulse /etc/selinux/targeted/contexts/files/file_contexts* /etc/selinux/targeted/contexts/files/file_contexts:/var/log/nocpulse(/.*)? system_u:object_r:spacewalk_monitoring_log_t:s0 # restorecon -nrvv /var/log/nocpulse restorecon reset /var/log/nocpulse/TSDBLocalQueue context system_u:object_r:var_log_t:s0->system_u:object_r:spacewalk_monitoring_log_t:s0 restorecon reset /var/log/nocpulse/TSDBLocalQueue/archive context system_u:object_r:var_log_t:s0->system_u:object_r:spacewalk_monitoring_log_t:s0 restorecon reset /var/log/nocpulse/TSDBLocalQueue/failed context system_u:object_r:var_log_t:s0->system_u:object_r:spacewalk_monitoring_log_t:s0 restorecon reset /var/log/nocpulse/TSDBLocalQueue/queue context system_u:object_r:var_log_t:s0->system_u:object_r:spacewalk_monitoring_log_t:s0 Why rpm did not set the context upon installation of the tsdb package is uncler to me. The tsdb package was installed after spacewalk-monitoring-selinux was installed. One possibility to tackle the problem is to require tsdb in spacewalk-monitoring-selinux, and thus relabel the directories in spacewalk-monitoring-selinux' %post. According to Jindřich N., it's not supposed to work when both packages are in the same transaction. So we now require tsdb in spacewalk-monitoring-selinux, so that we can restorecon its directories. Fix in Spacewalk repo, commit 2fa4874741b1448560eaf20175987ad8f4840a62. Fix is in spacewalk-monitoring-selinux-0.5.7-6-sat. Moving ON_QA verified 6/5 probe worked.. I did get the following though type=AVC msg=audit(1244481688.823:2940): avc: denied { getattr } for pid=11605 comm="gogo.pl" path="/var/lib/nocpulse/commands/heartbeat" dev=dm-0 ino=1578391 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=root:object_r:var_lib_t:s0 tclass=file Would you mind to file this new one as new bug? Verified in stage, SNMP probes work, no selinux denials -> RELEASE_PENDING An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html |