Description of problem: On a standard install of RHEL 6.3 there seems to be a process that creates the directory "1" in /root. Subsequently, this AVC is generated: SELinux is preventing /usr/sbin/sendmail.postfix from write access on the file /root/1. ***** Plugin leaks (86.2 confidence) suggests ****************************** If you want to ignore sendmail.postfix trying to write access the 1 file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/sbin/sendmail.postfix /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin leaks (86.2 confidence) suggests ****************************** If you want to ignore sendmail.postfix trying to write access the 1 file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/sbin/sendmail.postfix /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (14.7 confidence) suggests *************************** If you believe that sendmail.postfix should be allowed write access on the 1 file 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 sendmail /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp The SELinux info for the directory /root/1 is: -rw-r--r--. root root system_u:object_r:admin_home_t:s0 1 Version-Release number of selected component (if applicable): postfix-2.6.6-2.2.el6_1.x86_64 How reproducible: Don't know Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Sorry, /root/1 is a file, not a directory
What AVCs do you see? # ausearch -m avc -ts today
Lot's of these: time->Mon Sep 17 04:24:06 2012 type=SYSCALL msg=audit(1347848646.313:66786): arch=c000003e syscall=59 success=yes exit=0 a0=22d3330 a1=22cafc0 a2=1e3c330 a3=20 items=0 ppid=9449 pid=9452 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1569 comm="sendmail" exe="/usr/sbin/sendmail.postfix" subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1347848646.313:66786): avc: denied { write } for pid=9452 comm="sendmail" path="/root/1" dev=dm-0 ino=3201 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file BTW, I've traced the origin of /root/1 as being created by a cron job: 0 1 * * * root perl -le 'sleep rand 9000' && satellite-sync --email >/dev/null 2>1 This is an exact copy from the RHN Satellite User Guide (https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Network_Satellite/5.4/html-single/User_Guide/index.html#chap-User_Guide-Automatic_Synchronization) So, my guess is the "--mail" invokes postfix and postfix wants to write into 1 but is prevented by SElinux.
If it is really needed to use /root/1 file then it should be appended instead of write access.
In general, procedures in product documentation should work on a default install, or should describe the variations.
By default we do sendmail not postfix. https://access.redhat.com/site/documentation/en-US/Red_Hat_Network_Satellite/5.4/html-single/Installation_Guide/index.html#sect-Installation_Guide-Installation-Sendmail_Configuration My recommendation is to open a support case with Red Hat to replicate and confirm bug and align appropriately. Cliff
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days