selinux-policy-3.5.13-46.fc10.noarch - slight hiccup!

[Mike Cloaked]

Mike Cloaked wrote:
> 
> 
> "Summary
> SELinux is preventing procmail (procmail_t) "write" to ./tmp (usr_t). 
> Detailed Description
> SELinux denied access requested by procmail. It is not expected that this
> access is required by 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. 
> Allowing Access
> Sometimes labeling problems can cause SELinux denials. You could try to
> restore the default system file context for ./tmp, restorecon -v './tmp'
> If this does not work, there is currently no automatic way to allow this
> access. Instead, you can generate a local policy module to allow this
> access - see FAQ Or you can disable SELinux protection altogether.
> Disabling SELinux protection is not recommended. Please file a bug report
> against this package. 
> Additional Information
> Source Context:  system_u:system_r:procmail_t:s0
> Target Context:  system_u:object_r:usr_t:s0
> Target Objects:  ./tmp [ dir ]
> Source:  procmail
> Source Path:  /usr/bin/procmail"
> 
> I have rebooted and I have restorecon -vR /home as user - and of course
> this refers to ./tmp which is not in my home area so there is somewhere
> else that there is a wrongly set tmp directory now - and I can't find it!
> 
> This is not good - really not good.
> 

Seems that /var/spool/mail (which is bind mounted) had its contexts messed
up - and restorecon -vR /var/spool/mail seems to have fixed this issue.

In fact I wonder now if bind mounted directories are where the problem is
being seen?  In my case I have bind mounted user areas and bind mounted mail
spools...  perhaps if you don't have any bind mounts you don't see a
problem?
-- 
View this message in context: http://www.nabble.com/selinux-policy-3.5.13-46.fc10.noarch---slight-hiccup%21-tp22296524p22305447.html
Sent from the Fedora List mailing list archive at Nabble.com.