Description of problem: SELinux denied access requested by /usr/bin/procmail. It is not expected that this access is required by /usr/bin/procmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Version-Release number of selected component (if applicable): procmail v3.22 2001/09/10 How reproducible: The following error message is received in /var/log/maillog: Deferred: local mailer (/usr/bin/procmail) exited with EX_TEMPFAIL. Mail is not delivered to recipient. And a popup selinux "setrouble shoot browser" appears and says to file a bug report as there is no solution to this problem. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Mail may be sent from this machine to recipients on other machines. However, mail may not be received by the recipient. The mail just sits in /var/spool/mqueue and attempts delivery posting the above TEMPFAIL message in the maillog. I will continue to work on this problem independently. After all it may be something I put in the sendmail.cf file that's causing the error.
What avc messages are you seeing? What directory is labeled samba_share_t? Did you run chcon -R -t samba_share_t on a directory?
Here's a new twist. Just as your comment arrived, I discovered that deleting /var/mail/$USER, which was created upon account creation (and initialy worked), and then sending e-mail to that $USER worked! However, the "setrouble shoot browser" popup still appeared. And, does so every time a new e-mail is sent. Eventually, all of the tests to $USER were received. Now to answer your question. I'm personally not seeing any avc messages except for those reported in the "setrouble shoot browser" popup as follows: avc: denied { search } for comm="procmail" dev=hda2 egid=12 euid=0 exe="/usr/bin/procmail" exit=-13 fsgid=12 fsuid=0 gid=12 items=0 name="/" pid=5653 scontext=system_u:system_r:procmail_t:s0 sgid=12 subj=system_u:system_r:procmail_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:samba_share_t:s0 tty=(none) uid=0 I have no idea which directory is labeled samba_share_t. Neither a locate nor a find discovered any directory/file labeled samba_share_t. So would executing "chcon -R -t samba_share_t" do anything? I tried it out and the results are as follows: # chcon -R -t samba_share_t chcon: too few arguments Try `chcon --help' for more information.
ls -ldZ / find / -context "*samba_share_t*"
Ok, thanks for the help. It appears I have many directories labeled samba_share_t. I don't remember labeling any of them samba_share_t. But in my effort to port my former samba files to EL5, I may have inadevertently done that. How would I go about fixing that?
In looking back through my notes on samba, I did issue the command "chcon -R -t samba_share_t /." This was recommended by a browser popup error as follows: SELinux is preventing samba (/usr/sbin/smbd) "search" to / (default_t). SELinux denied samba access to /. If you want to share this directory with samba it has to have a file context label of samba_share_t. The following command will allow this access: chcon -R -t samba_share_t / I had a following problem: SELinux is preventing /sbin/mcstransd (setrans_t) "search" access to / (samba_share_t). It was recommended to try "restorecon -v /." I didn't do this, then. I'll try now. That didn't reverse the labeling. I'll check the FAQ for a policy to try.
Looks like I already tried the policy in the FAQ. I think I'm screwed. Best bet looks like I need to restore the system back to before I started porting samba. Since I've got backups running now, I'll do this Monday. Unless you have any further suggestions, I guess we can close this bug report. Thanks for pointing me in the right direction.
Ok, I tried changing context labels back to what they were supposed to be using chcon -R -t home_root_t /home, then cd /home and chcon -R -t user_home_dir_t *. Then, I changed the dirctories with samba_share_t to default_t. And, after a reboot, it looks like the popup error on procmail has disappeared. I have a similar problem with clamscan, but it looks like more of the same. I'll just have to figure out the proper context label for mdefang-m0PNhDXM004085 (var_spool_t) as in SELinux is preventing /usr/bin/clamscan (clamscan_t) "search" access to mdefang-m0PNhDXM004085 (var_spool_t).
restorecon -F -v -R PATH Should set the machine back to the system defaults.
Also we are preparing an update to RHEL5 policy for Update 2. You can get a test version at http://people.redhat.com/dwalsh/SELinux/RHEL5
Thanks for the command. I have reset all file contexts and hope this solves my problem with them. Might as well try the 2.4.6-117 versions . Thanks for tip. When these are released will they update automatucally?
Yes it you are a RHEL5 subscriber, you will get this update.