Bug 499680 - Satellite continues to have monitoring related selinux failures/messages after monitoring turned off
Satellite continues to have monitoring related selinux failures/messages afte...
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Monitoring (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Suchý
wes hayutin
na
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-07 12:23 EDT by wes hayutin
Modified: 2009-06-08 13:51 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-08 13:12:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wes hayutin 2009-05-07 12:23:21 EDT
Description of problem:

5/1 build on rhel 5

recreate:
1. configure monitoring
2. setup probles ie.. mysql, rpc etc..
3. make sure probes work
4. turn off monitoring in satellite webui
5. restart satellite

tail the audit.log, watch as you still receive selinux messages related to satellite monitoring..

expected results:

all monitoring process should really stop after disabling and restarting the satellite.

acewalk_monitoring_t:s0 tcontext=system_u:object_r:mysqld_etc_t:s0 tclass=file
type=SYSCALL msg=audit(1241713068.572:4084): arch=40000003 syscall=195 success=no exit=-13 a0=bff87cce a1=bff84c6c a2=b41ff4 a3=bff84c6c items=0 ppid=25651 pid=25658 auid=0 uid=103 gid=105 euid=103 suid=103 fsuid=103 egid=105 sgid=105 fsgid=105 tty=pts1 ses=422 comm="mysql" exe="/usr/bin/mysql" subj=root:system_r:spacewalk_monitoring_t:s0 key=(null)
type=AVC msg=audit(1241713068.572:4085): avc:  denied  { name_connect } for  pid=25658 comm="mysql" dest=3306 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1241713068.572:4085): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bff87740 a2=4eac00 a3=0 items=0 ppid=25651 pid=25658 auid=0 uid=103 gid=105 euid=103 suid=103 fsuid=103 egid=105 sgid=105 fsgid=105 tty=pts1 ses=422 comm="mysql" exe="/usr/bin/mysql" subj=root:system_r:spacewalk_monitoring_t:s0 key=(null)

[root@grandprix ~]# /etc/init.d/Monitoring status
2009-05-07 12:18:53 Monitoring: ----------- InstallSoftwareConfig STATUS ---------------
[root@grandprix ~]# /etc/init.d/MonitoringScout status
2009-05-07 12:19:01 MonitoringScout: ----------- InstallSoftwareConfig STATUS ---------------
2009-05-07 12:19:01 MonitoringScout: ----------- NPBootstrap STATUS ---------------
2009-05-07 12:19:01 MonitoringScout: ----------- SputLite STATUS ---------------
2009-05-07 12:19:02 MonitoringScout: ----------- Dequeuer STATUS ---------------
2009-05-07 12:19:02 MonitoringScout: ----------- Dispatcher STATUS ---------------
[root@grandprix ~]#
Comment 1 Jan Pazdziora 2009-05-23 01:33:17 EDT
Mirek, I suspect the problem is that even if Monitoring is off, MonitoringScout is still on and running the probes. Anyway, the mysql name_connect AVC is being tracked in bug 498053 which is ON_QA as of Satellite-5.3.0-RHEL5-re20090520.0. So with latest composes this bugzilla should be addressed as well.

Of course, we might take this opportunity to see if perhaps shutting down Monitoring shouldn't stop the scout or probes in it as well.
Comment 2 Miroslav Suchý 2009-05-28 07:49:31 EDT
Since AVC is duplicate of 498053.
The behavior that MonitoringScout is still running even when MonitoringBackend is disabled has always worked this way. The correct behavior is unclear to me. I started discussion on spacewalk-devel mailing list and I suggest to punt this BZ to next release.
Comment 3 Clifford Perry 2009-05-28 09:32:58 EDT
Agree, Scout running independent of Backend has always been such. Lets leave this beast of a bug for another release. 

Cliff
Comment 4 Brandon Perkins 2009-06-03 12:58:33 EDT
This issue is causing a few headaches on the QA side in testing sat530.  Throwing back on Triage so Cliff and I can discuss.
Comment 5 Brandon Perkins 2009-06-04 13:01:03 EDT
Wes, when you say "disable monitoring"  are you disabling both the monitoring and the scout?  If you're still running the scout but not running the monitoring, the scout has every right to still be running.  If, however both are off and you're seeing this, then that is a different issue.
Comment 6 wes hayutin 2009-06-08 13:12:17 EDT
this no longer seems to be an issue in 6/5

Note You need to log in before you can comment on or make changes to this bug.