Summary: SELinux is preventing /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr access to a leaked /dev/pts/2 file descriptor. Detailed Description: [tnslsnr has a permissive type (oracle_tnslsnr_t). This access was not denied.] SELinux denied access requested by the tnslsnr command. It looks like this is either a leaked descriptor or tnslsnr output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /dev/pts/2. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context unconfined_u:system_r:oracle_tnslsnr_t:s0 Target Context unconfined_u:object_r:user_devpts_t:s0 Target Objects /dev/pts/2 [ chr_file ] Source tnslsnr Source Path /usr/lib/oracle/xe/app/oracle/product/10.2.0/serve r/bin/tnslsnr Port <Unknown> Host (removed) Source RPM Packages oracle-xe-univ-10.2.0.1-1.0 Target RPM Packages Policy RPM selinux-policy-3.7.19-54.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks Host Name (removed) Platform Linux (removed) 2.6.34.6-54.fc13.i686.PAE #1 SMP Sun Sep 5 17:33:43 UTC 2010 i686 i686 Alert Count 1 First Seen Mon 20 Sep 2010 04:10:56 PM MST Last Seen Mon 20 Sep 2010 04:10:56 PM MST Local ID 496f099e-da6f-4bdc-8efe-f7c71b4049da Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1285024256.174:76): avc: denied { append } for pid=4039 comm="tnslsnr" path="/dev/pts/2" dev=devpts ino=5 scontext=unconfined_u:system_r:oracle_tnslsnr_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file node=(removed) type=SYSCALL msg=audit(1285024256.174:76): arch=40000003 syscall=11 per=400000 success=yes exit=0 a0=88dd180 a1=88dd150 a2=88dd220 a3=88dd150 items=0 ppid=1 pid=4039 auid=500 uid=250 gid=250 euid=250 suid=250 fsuid=250 egid=250 sgid=250 fsgid=250 tty=(none) ses=1 comm="tnslsnr" exe="/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr" subj=unconfined_u:system_r:oracle_tnslsnr_t:s0 key=(null) Hash String generated from leaks,tnslsnr,oracle_tnslsnr_t,user_devpts_t,chr_file,append audit2allow suggests: #============= oracle_tnslsnr_t ============== allow oracle_tnslsnr_t user_devpts_t:chr_file append;
Taking. Frank, does this AVC denial happen during installation / configuration of the Oracle XE, or when you further install Spacewalk, or perhaps when rebooting the system? Thank you for clarification, Jan
It appears to definitely be doing this upon reboot. It also may have occurred during the installation/configuration as well.
Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2.
Mass-moving to space13.
(In reply to comment #2) > It appears to definitely be doing this upon reboot. It also may have occurred > during the installation/configuration as well. Alright, this is however important distinction. Do you really have two AVC denials in the audit.log?
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
We don't seem to have more details about how many AVCs there were. No similar report found, closing now.