Well, I'm stuck here if there's no easy way to fix my problem. I
can't understand how daemons such as syslogd or crond are not allowed
to send emails through postfix. I'm only left with an option, disable
selinux, which sucks. I tried to read the documentation and it's a
lot to swallow. On top of that, FC5 has different locations for all
those files, different from what the selinux documentation says. For
example, I don't have a src directory inside /etc/selinux/targeted/
and there's no single file ending with .te in my system.
This is frustrating. Thanks for your help Dave
EJ
PS. The selinux list is completely dead, one email in 24 hours. So
much for getting help there.
On Jul 8, 2006, at 9:48 AM, David G. Miller wrote:
redhatdude@xxxxxxxxxxxxx wrote:
So far no answer from the selinux list, it doesn't seem to have
much activity that list. Can someone here help me out with this
issue? Thanks, EJ On Jul 7, 2006, at 4:15 PM, Paul Howarth wrote:
On Fri, 2006-07-07 at 14:13 -0400, redhatdude@xxxxxxxxxxxxx wrote:
Hi,
While trying to set up a mail cgi script, I discovered that
Selinux
is not allowing relaying mail from anything but postfix. I
realized
this when I turned off selinux and I started getting the
result of
cron jobs and other similar system emails.
So my question is , how can I make selinux allow programs
other than
postfix and cyrus to relay emails?
You need to raise this on fedora-selinux-list.
If it's a policy issue, the right people will see it there.
Paul.
Lots of differences between our two setups since I'm running
sendmail and you're running postfix but I ran into a similar
problem when I wanted to get DSPAM working. The following are the
rulesets that "audit2allow" came up with to make things work:
cat /etc/selinux/targeted/src/policy/domains/misc/local.te
allow httpd_sys_script_t httpd_t:dir getattr;
allow httpd_sys_script_t initrc_t:dir getattr;
allow httpd_sys_script_t initrc_var_run_t:file read;
allow httpd_sys_script_t mysqld_t:dir getattr;
allow httpd_sys_script_t ntpd_t:dir getattr;
allow httpd_sys_script_t portmap_t:dir getattr;
allow httpd_sys_script_t syslogd_t:dir getattr;
# Next generated by audit2allow but causes compilation error.
DSPAM appears
# to work OK without it.
# allow httpd_sys_script_t unconfined_t:dir getattr;
allow httpd_sys_script_t usr_t:dir { add_name remove_name write };
allow httpd_sys_script_t usr_t:file { append create lock unlink
write };
allow httpd_t httpd_sys_content_t:file execute;
allow ndc_t named_zone_t:file { getattr read };
allow httpd_sys_script_t httpd_t:dir search;
allow httpd_sys_script_t initrc_t:dir search;
allow httpd_sys_script_t initrc_var_run_t:file lock;
allow httpd_sys_script_t mysqld_t:dir search;
allow httpd_sys_script_t ntpd_t:dir search;
allow httpd_sys_script_t portmap_t:dir search;
allow httpd_sys_script_t syslogd_t:dir search;
You can see from my comments that this was somewhat of a trial and
error approach to making DSPAM work. For DSPAM, I also had to play
with regular directory permissions and ownership within /var/spool/
mail and the DSPAM directories. Finally, my regular admin mail
(cron jobs, logwatch, etc.) all worked fine without these rule
changes so it sounds like you may have other SELinux issues.
Put the rules into /etc/selinux/targeted/src/policy/domains/misc/
local.te and then do a make, make install in /etc/selinux/targeted/
src/policy/. If these rules don't work, you can use the same
methodology I used: turn off SELinux enforcement and perform the
actions you're interested in then run audit2allow to see what local
rules you need. Be advised that the local rules that audit2allow
creates may be loser than necessary and may open a vulnerability.
Cheers,
Dave
--
Politics, n. Strife of interests masquerading as a contest of
principles.
-- Ambrose Bierce
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list