Bug 498611 - TNS Oracle:Ping probe returns critical if selinux is enforcing, works in permissive
Summary: TNS Oracle:Ping probe returns critical if selinux is enforcing, works in perm...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Monitoring
Version: 530
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: wes hayutin
URL: http://grandprix.rhndev.redhat.com/rh...
Whiteboard:
: 505012 505144 (view as bug list)
Depends On: 474279
Blocks: 457079 463877
TreeView+ depends on / blocked
 
Reported: 2009-05-01 13:41 UTC by wes hayutin
Modified: 2009-09-10 18:49 UTC (History)
5 users (show)

Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-10 18:49:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
audit.log (18.66 KB, text/plain)
2009-05-01 13:41 UTC, wes hayutin
no flags Details

Description wes hayutin 2009-05-01 13:41:36 UTC
Created attachment 342088 [details]
audit.log

Description of problem:

sat 4/24.1 rhel 5 build.

recreate.
1. setup monitoring 
2. create the tns oracle ping probe
3. register a client w/ oracle 10.2 running (in this case I used another satellite as the client)
4. open up outside connections on the oracle server (listener.ora)
5. push scout 

selinux on...  

[root@grandprix ~]# su - nocpulse
-bash-3.2$ rhn-runprobe 110
2009-05-01 09:31:47 	Items changed or removed:
2009-05-01 09:31:47 		latency '0.00055694580078125' is OK
2009-05-01 09:31:47 		Host is unreachable  '10.10.76.52' is CRITICAL
2009-05-01 09:31:47 	Would notify because:
2009-05-01 09:31:47 		Host is unreachable  '' is OK
2009-05-01 09:31:47 	NOTE: Running in test mode; no changes saved, nothing enqueued
2009-05-01 09:31:47 
============================================================
OK: TNS Listener: Latency 0.001 sec
============================================================

selinux permissive
push scout again

-bash-3.2$ rhn-runprobe 110
2009-05-01 09:33:32 	No items changed
2009-05-01 09:33:32 	Notification not required
2009-05-01 09:33:32 	NOTE: Running in test mode; no changes saved, nothing enqueued
2009-05-01 09:33:32 
============================================================
OK: TNS Listener: Latency 0.001 sec
============================================================
-bash-3.2$ 


I dont see anything relevant in the audit.log unfortunately.

Comment 1 wes hayutin 2009-05-01 13:45:19 UTC
so one thing to note about the bug... 
A scout config push is *required* after changing the selinux config on the satellite server to recreate successfully..

example.
probe is working, server in permissve..

1. senenforce 1
2. push scout config on webui..

run probe again, now it will fail.

Comment 2 Jan Pazdziora 2009-05-25 13:33:21 UTC
Due to the way bug 474279 was fixed, the TNS Ping gives bogus results anyway. I assume the machine 10.10.76.52 was really unreachable.

Comment 3 Miroslav Suchý 2009-06-08 09:47:51 UTC
AVC messages from audit.log:
type=AVC msg=audit(1244462055.947:1889): avc:  denied  { getattr } for  pid=29020 comm="kernel.pl" path="/var/lib/nocpulse/libexec/Oracle/TNSping.pm" dev=xvda1 ino=1229898 scontext=user_u:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1244462055.947:1889): arch=40000003 syscall=195 success=yes exit=0 a0=9c739c0 a1=bfe7988c a2=b7eff4 a3=9c739c0 items=0 ppid=11049 pid=29020 auid=0 uid=102 gid=104 euid=102 suid=102 fsuid=102 egid=104 sgid=104 fsgid=104 tty=(none) ses=183 comm="kernel.pl" exe="/usr/bin/perl" subj=user_u:system_r:spacewalk_monitoring_t:s0 key=(null)
type=AVC msg=audit(1244462055.967:1890): avc:  denied  { read } for  pid=29020 comm="kernel.pl" name="TNSping.pm" dev=xvda1 ino=1229898 scontext=user_u:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1244462055.967:1890): arch=40000003 syscall=5 success=yes exit=8 a0=9c73ca8 a1=8000 a2=0 a3=8000 items=0 ppid=11049 pid=29020 auid=0 uid=102 gid=104 euid=102 suid=102 fsuid=102 egid=104 sgid=104 fsgid=104 tty=(none) ses=183 comm="kernel.pl" exe="/usr/bin/perl" subj=user_u:system_r:spacewalk_monitoring_t:s0 key=(null)
type=AVC msg=audit(1244462055.971:1891): avc:  denied  { ioctl } for  pid=29020 comm="kernel.pl" path="/var/lib/nocpulse/libexec/Oracle/TNSping.pm" dev=xvda1 ino=1229898 scontext=user_u:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1244462055.971:1891): arch=40000003 syscall=54 success=no exit=-25 a0=8 a1=5401 a2=bfe79688 a3=bfe796c8 items=0 ppid=11049 pid=29020 auid=0 uid=102 gid=104 euid=102 suid=102 fsuid=102 egid=104 sgid=104 fsgid=104 tty=(none) ses=183 comm="kernel.pl" exe="/usr/bin/perl" subj=user_u:system_r:spacewalk_monitoring_t:s0 key=(null)
type=AVC msg=audit(1244462056.211:1892): avc:  denied  { append } for  pid=29025 comm="ifconfig" path="/var/lib/nocpulse/NPkernel.out/29020.STDERR" dev=xvda1 ino=979377 scontext=user_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1244462056.211:1892): arch=40000003 syscall=11 success=yes exit=0 a0=9c56d90 a1=9ccc148 a2=8b84b58 a3=8b71008 items=0 ppid=29020 pid=29025 auid=0 uid=102 gid=104 euid=102 suid=102 fsuid=102 egid=104 sgid=104 fsgid=104 tty=(none) ses=183 comm="ifconfig" exe="/sbin/ifconfig" subj=user_u:system_r:ifconfig_t:s0 key=(null)

Comment 4 Miroslav Suchý 2009-06-09 15:09:58 UTC
Commited as 76bdc6d40df51d085b0ba78866ba65c2344df757 and 249f66e71268a8f05ee376c989a51d1cdc719bce

Comment 5 Miroslav Suchý 2009-06-10 15:26:10 UTC
The problem with wrong selinux context on some file I just reported in https://bugzilla.redhat.com/show_bug.cgi?id=505066

if we run:
      yum install spacewalk-monitoring-selinux perl-NOCpulse-Scheduler
    then
     ls -ldZ /usr/lib/perl5/vendor_perl/5.8.8/NOCpulse/Scheduler
    drwxr-xr-x  root root system_u:object_r:lib_t          /usr/lib/perl5/vendor_perl/5.8.8/NOCpulse/Scheduler
    will have wrong context. This seem to be bug in rpm or selinux. As workaround we run restorecon in %posttrans when all files are already installed.

I change %post to %posttrans (commits b4a7b0407d3d4470fa9ad3a5700329eff2e9e1d0 and 58bb0bbfa3b6df17d21974b7edab747e5795370d) which should make workaround for us.

Comment 6 Miroslav Suchý 2009-06-11 08:33:24 UTC
*** Bug 505012 has been marked as a duplicate of this bug. ***

Comment 7 Miroslav Suchý 2009-06-11 08:36:44 UTC
*** Bug 505144 has been marked as a duplicate of this bug. ***

Comment 8 Miroslav Suchý 2009-06-12 12:59:35 UTC
compose 20090612
moving ON_QA

Comment 9 Jan Pazdziora 2009-06-12 14:31:25 UTC
Mirek, there seems to be a problem with that %posttrans approach -- osa-dispatcher-selinux presumably was not changed:

^M  Installing     : spacewalk-setup                               [268/272] 
^M  Installing     : spacewalk-schema                              [269/272] 
^M  Installing     : spacewalk-selinux                             [270/272] 
^M  Installing     : satellite-schema                              [271/272] 
^M  Installing     : osa-dispatcher-selinux                        [272/272]libsepol.print_missing_requirements: osa-dispatcher's global requirements were not met: type/attribute spacewalk_log_t
libsemanage.semanage_link_sandbox: Link packages failed
/usr/sbin/semodule:  Failed!

I also wonder if the order in which the scripts are invoked in %posttrans is guaranteed to be the same is the order of the package installation (== as the order when run in %post).

Comment 10 Miroslav Suchý 2009-06-15 07:35:20 UTC
Yes, I forgot on osad.
Commit 7e85d5f5fda5ff1c3060b5e31f492492fc191b16

Comment 11 Miroslav Suchý 2009-06-15 07:51:25 UTC
According to jnovy there is no guaranteed order of %posttrans :(
Therefore we will need to split %{_sbindir}/%{name}-enable into two parts.
semodule -i should be called in %post when we have guaranteed order due requires
and in %posttrans we can restorecon and there is no need of dependency then.

Comment 12 Miroslav Suchý 2009-06-15 09:50:46 UTC
Commited as e67b06c188f5850a5ce89632b8171ce06bb0ed7b

Comment 13 Miroslav Suchý 2009-06-17 08:05:04 UTC
is on iso 20090616
moving to ON_QA

Comment 14 wes hayutin 2009-06-19 15:40:04 UTC
going to pass this... 6/16 build

I had to set selinux to 0 to get the scout to pick up my oracle probes.  
Ran the rhn-runprobe and it worked..

turned selinux back to 1 and 

[root@grandprix .ssh]# su - nocpulse
-bash-3.2$ rhn-runprobe 67
2009-06-19 11:37:43 	No items changed
2009-06-19 11:37:43 	Notification not required
2009-06-19 11:37:43 	NOTE: Running in test mode; no changes saved, nothing enqueued
2009-06-19 11:37:43 
============================================================
OK: TNS Listener: Latency 0.008 sec
============================================================
-bash-3.2$ exit
logout
[root@grandprix .ssh]# getenforce 
Enforcing
[root@grandprix .ssh]# su - nocpulse
-bash-3.2$ rhn-runprobe 67
2009-06-19 11:38:10 	No items changed
2009-06-19 11:38:10 	Notification not required
2009-06-19 11:38:10 	NOTE: Running in test mode; no changes saved, nothing enqueued
2009-06-19 11:38:10 
============================================================
OK: TNS Listener: Latency 0.008 sec
============================================================


verifed, for no support ;)

Comment 15 Milan Zázrivec 2009-09-09 08:50:33 UTC
$ rhn-runprobe --live 1
2009-09-09 04:49:49     No items changed
2009-09-09 04:49:49     Notification not required
2009-09-09 04:49:49 
============================================================
OK: TNS Listener: Latency 0.260 sec
============================================================

RELEASE_PENDING

Comment 16 Brandon Perkins 2009-09-10 18:49:30 UTC
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


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