Tough to come up with a subject for this one; it's really messing with
my fragile mind. I have a system running RT3, which uses mod_perl or
somesuch to run within the web server process. It needs to send mail,
so it calls /usr/bin/sendmail, which happens to be exim on this system.
If I understand things correctly, the sendmail process is supposed to
start as or somehow transition to exim_t where it is then allowed to
access whatever exim_t is allowed to access.
This was all working until I had to reboot the machine for unrelated
reasons today. Now, RT3 can't send mail, and the audit logs seem to
indicate that httpd_t is being denied things like writing to the exim
spool file location. It really seems like somehow the transition to
exim_t is not happening. Perhaps this will illustrate:
> s ausearch -ts today |grep exim|audit2allow
#============= httpd_t ==============
allow httpd_t exim_spool_t:dir { search setattr read write getattr remove_name open add_name };
allow httpd_t exim_spool_t:file { rename setattr read lock create write getattr unlink open append };
allow httpd_t proc_net_t:file { read getattr open };
allow httpd_t self:capability fowner;
allow httpd_t smtp_port_t:tcp_socket name_connect;
Currently I've simply disabled selinux until I can understand what has
happened. yum.log indicates that selinux-policy(-targeted) were updated
on the 13th, but everything was working fine up until the today's
reboot. No other related packages have been updated recently, and
nothing was updated today. I suppose the reboot did boot me into a new
kernel version (from kernel-2.6.29.6-217.2.3.fc11.x86_64 to
kernel-2.6.30.5-43.fc11.x86_64).
> ls -lZ /usr/sbin/exim
-rwsr-xr-x. root root system_u:object_r:exim_exec_t:s0 /usr/sbin/exim*
(which is what /usr/bin/sendmail is linked to via half a dozen symlinks
due to alternatives).
- J<
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
