Description of problem: Root has a .forward file to forward email to another user. Sendmail reports: sendmail[19969]: n2BGgM8u019968: forward /root/.forward: Permission denied Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.8-2.fc11.noarch How reproducible: Always Steps to Reproduce: 1.Create a .forward file on root 2.Send an email to root 3. Actual results: Permission denied error Expected results: Email gets forwarded Additional info: I created a local policy with audit2allow -l -a -m localxxx to work around the problem: module local016 1.0; require { type sendmail_t; type admin_home_t; class file { read getattr open }; } #============= sendmail_t ============== allow sendmail_t admin_home_t:file { read getattr open };
I've had the same problem on my rawhide system since December 8, 2008, just a few hours after this update: Dec 08 13:05:49 Updated: sendmail-8.14.3-2.fc11.i386 Dec 08 13:08:25 Updated: selinux-policy-targeted-3.6.1-6.fc11.noarch I tried loading the local policy shown above, and it didn't make a difference. Using the sealert -b browser, there seems to have been only 5 AVC denied messages related to sendmail attempting to access /root/.forward, and the most recent of them was December 10. I tried changing the mode on /root to readable and searchable by all (755) and that didn't help. What did help was "setenforce 0", so clearly it is an SELinux problem, but why are we getting SELinux denials with nothing being logged in /var/log/audit/audit.log?
Yeah, I confirmed the local policy change no longer works with the current policy, and there's no audit but setenforce 0 does work. I changed the sendmail aliases as a workaround, but that's not as dynamic. A permission denied without an audit is troubling.
Fixed in selinux-policy-3.6.10-4.fc11.noarch
Thanks, Daniel. Does the new policy fix the problem with access to /root/.forward, the problem with denials not getting logged, or both? Should I open a new bug report for the lack of audits in the log?