Bug 171194 - selinux update breaks spamassassin/procmail?
selinux update breaks spamassassin/procmail?
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-19 06:36 EDT by Darren Brierton
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: 1.27.1-2.11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-14 15:53:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
local.te (see previous comment) (1.25 KB, text/plain)
2005-10-20 10:53 EDT, Darren Brierton
no flags Details
bzip2 of /var/log/audit/audit.log (298.05 KB, application/octet-stream)
2005-10-20 13:45 EDT, Darren Brierton
no flags Details

  None (edit)
Description Darren Brierton 2005-10-19 06:36:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I've just been searching through bugzilla but I can't find this reported yet. Yesterday I upgraded to the latest versions of selinux-policy-* from updates-released:

selinux-policy-strict-1.27.1-2.6
selinux-policy-strict-sources-1.27.1-2.6
selinux-policy-targeted-1.27.1-2.6
selinux-policy-targeted-sources-1.27.1-2.6

Since then spam filtering has stopped working. My spamassassin setup is as follows: fetchmail pulls mail from various POP3 servers and delivers it to a locally running postfix. My ~/.forward file is:

"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #darren"

and the first line of my ~/.procmailrc is:

INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

This has worked very well for me for a long time now. However since yesterday's update it no longer is. I am seeing messages in /var/log/audit/audit.log like this:

type=AVC msg=audit(1129716919.493:40): avc:  denied  { search } for
pid=3333 comm="procmail" name="mail" dev=hda3 ino=1890406
scontext=system_u:system_r:postfix_local_t
tcontext=system_u:object_r:etc_mail_t tclass=dir
type=SYSCALL msg=audit(1129716919.493:40): arch=40000003 syscall=195
success=no
exit=-13 a0=8f22a96 a1=bf93a114 a2=9b7ff4 a3=8f20d3a items=1 pid=3333
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500
sgid=500 fsgid=500 comm="procmail" exe="/usr/bin/procmail"
type=CWD msg=audit(1129716919.493:40):  cwd="/home/darren"
type=PATH msg=audit(1129716919.493:40): item=0
name="/etc/mail/spamassassin/spamassassin-spamc.rc" flags=1
inode=1890406 dev=03:03 mode=040755 ouid=0 ogid=0 rdev=00:00

Unfortunately I do not grok audit.log's messages, but this seems to me to be saying that selinux is denying procmail from piping my mail though spamd with spamc.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.27.1-2.6

How reproducible:
Always

Steps to Reproduce:
1. blah
2. blah
3. blah
  

Additional info:
Comment 1 Darren Brierton 2005-10-20 06:50:28 EDT
I'm elevating this to HIGH because with no spam filtering I am being overwhelmed
with spam to the extent that it is difficult to get anything else done.
Comment 2 Stephen Smalley 2005-10-20 08:06:29 EDT
Note that until a policy update arrives, you can add the necessary permissions
locally to your policy via the sequence described in the EXAMPLE section of the
audit2allow(1) man page.  
Comment 3 Daniel Walsh 2005-10-20 09:03:08 EDT
Please try the policy on 

ftp://people.redhat.com/dwalsh/SELinux/FC4/selinux-policy-targeted-1.27.1-2.9

If this works for you I will put it into fedora test.  This policy adds policy
for spamd.
Comment 4 Darren Brierton 2005-10-20 09:38:36 EDT
(In reply to comment #3)
> Please try the policy on 
> 
> ftp://people.redhat.com/dwalsh/SELinux/FC4/selinux-policy-targeted-1.27.1-2.9
> 
> If this works for you I will put it into fedora test.  This policy adds policy
> for spamd.

Thanks, Daniel. I've installed your new packages. I'll keep an eye on the mail
logs for half an hour or so and then report back.
Comment 5 Darren Brierton 2005-10-20 09:41:25 EDT
Do I need to restart anything (postfix, spamassassin) once I've installed the
updates? Although it's only been a couple of minutes I'm seeing no improvements.
Comment 6 Darren Brierton 2005-10-20 10:03:28 EDT
Okay, even with your new packages installed spam filtering is definitely still
not working. I can tell just by examining the headers of mail messages once
they've been delivered.

For example, here is an excerpt from /var/log/maillog:

Oct 20 15:00:40 excession postfix/smtpd[7584]: 7DA00431FB2:
client=excession.dzr[127.0.0.1]
Oct 20 15:00:40 excession postfix/cleanup[7587]: 7DA00431FB2:
message-id=<898101c5d57e$02cdd6fd$3eae975d@yj252n1>
Oct 20 15:00:40 excession postfix/qmgr[2225]: 7DA00431FB2:
from=<loretta_coloncw@iname.com>, size=3107, nrcpt=1 (queue active)
Oct 20 15:00:40 excession postfix/local[7588]: 7DA00431FB2:
to=<darren@localhost.excession.dzr>, orig_to=<darren@localhost>, relay=local,
delay=0, status=sent (delivered to command: IFS=' ' && exec /usr/bin/procmail
-f- || exit 75 #darren)
Oct 20 15:00:40 excession postfix/qmgr[2225]: 7DA00431FB2: removed

And here is the relevant part from /var/log/audit/audit.log:

type=AVC msg=audit(1129816840.688:655): avc:  denied  { search } for  pid=7593
comm="procmail" name="mail" dev=hda3 ino=1890406
scontext=system_u:system_r:postfix_local_t tcontext=system_u:object_r:etc_mail_t
tclass=dir
type=SYSCALL msg=audit(1129816840.688:655): arch=40000003 syscall=195 success=no
exit=-13 a0=90afa96 a1=bffaf104 a2=9b7ff4 a3=90add3a items=1 pid=7593
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500
fsgid=500 comm="procmail" exe="/usr/bin/procmail"
type=CWD msg=audit(1129816840.688:655):  cwd="/home/darren"
type=PATH msg=audit(1129816840.688:655): item=0
name="/etc/mail/spamassassin/spamassassin-spamc.rc" flags=1  inode=1890406
dev=03:03 mode=040755 ouid=0 ogid=0 rdev=00:00

(Well, I think that was the relevant bit of audit.log. I don't exactly
understand to well what that stuff means.)
Comment 7 Stephen Smalley 2005-10-20 10:09:39 EDT
Switch to permissive mode (/usr/sbin/setenforce 0), run for a little while to
collect the audit messages related to your issue, then follow the steps listed
in the EXAMPLE section of the audit2allow(1) man page to add the necessary
permissions to your policy locally, and attach the resulting local.te file here
for consideration in a policy update.
Comment 8 Darren Brierton 2005-10-20 10:51:45 EDT
Okay, this is what I did.

# /usr/sbin/setenforce 0

Waited for about twenty minutes until I could see some mail that had definitely
been filtered through spamassassin. Then,

# cd /etc/selinux/targeted/src/policy/
# /usr/bin/audit2allow -i < /var/log/audit/audit.log >> domains/misc/local.te

I'll attach the local.te next.

However, if I understand what I've just done, I now will not be able to
determine whether any updates fix this problem as I have a local workaround in
place. How can I return my system to its former state (given that I was stupid
enough to not make a backup of the original local.te)?
Comment 9 Darren Brierton 2005-10-20 10:53:44 EDT
Created attachment 120192 [details]
local.te (see previous comment)
Comment 10 Stephen Smalley 2005-10-20 10:59:22 EDT
First, you need to also do a 'make load' in the policy directory if you want the
regenerated policy with the new local.te to be loaded into your kernel for
enforcement (at which point you can switch back to enforcing mode and verify
that it all works).

Second, local.te is purely for your own local customizations, so you can empty
it out at any time if you want to re-test against pristine policy.  If you
already had some entries in it from prior customizations, you should be able to
distinguish the postfix bits from the rest based on the types.
Comment 11 Daniel Walsh 2005-10-20 11:35:31 EDT
Ok lets add this to your local.te file.

domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t)

Also attach your audit.log file 

What is causing these?  Might be a mislabeled file system or actual policy bugs.
allow cupsd_config_t lib_t:dir write;
allow cupsd_config_t usr_t:dir write;
allow cupsd_config_t var_t:dir create;
allow cupsd_config_t var_t:file { read write };
allow dhcpc_t tmp_t:chr_file read;
allow httpd_t jabber_client_port_t:tcp_socket name_connect;
allow httpd_t usr_t:dir write;
allow nmbd_t samba_log_t:dir remove_name;
allow ping_t locale_t:file read;
allow ping_t self:unix_dgram_socket create;

The transition to spamd should fix these.
allow postfix_local_t etc_mail_t:dir search;
allow postfix_local_t etc_mail_t:file { getattr read };
Comment 12 Darren Brierton 2005-10-20 12:12:43 EDT
(In reply to comment #11)
> Ok lets add this to your local.te file.
> 
> domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t)

I'm assuming you want me to add that, do a 'make load' in the directory as per
comment #10, and then do a setenforce 1. Then I presume you want to know if spam
filtering starts working.

> Also attach your audit.log file 

No problem, I'll do that next. Again, I'm assuming you want the audit.log file
after the system has been running with the above changes for a couple of minutes.

> What is causing these?  Might be a mislabeled file system or actual policy bugs.
> allow cupsd_config_t lib_t:dir write;
> allow cupsd_config_t usr_t:dir write;
> allow cupsd_config_t var_t:dir create;
> allow cupsd_config_t var_t:file { read write };
> allow dhcpc_t tmp_t:chr_file read;
> allow httpd_t jabber_client_port_t:tcp_socket name_connect;
> allow httpd_t usr_t:dir write;
> allow nmbd_t samba_log_t:dir remove_name;
> allow ping_t locale_t:file read;
> allow ping_t self:unix_dgram_socket create;

I really don't know. The only one that seems related to anything I've been
working on is the jabber line, which is part of a PHP web application I'm
working on which sends messages out to jabber clients. I've no idea about any of
the others.
Comment 13 Darren Brierton 2005-10-20 12:20:17 EDT
Daniel, I've realised that I may have misunderstood your comment #11. Did you
want me to first remove what audit2allow added to local.te and replace it with
domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t)? I simply added it,
but in retrospect I'm guessing that that will prove nothing with at least

allow postfix_local_t etc_mail_t:dir search;
allow postfix_local_t etc_mail_t:file { getattr read };

still in local.te.
Comment 14 Daniel Walsh 2005-10-20 12:36:43 EDT
Yes remove those lines.

You can remove httpd_t jabber line also, and turn on the boolean

setsebool -P httpd_can_network_connect=1
Comment 15 Darren Brierton 2005-10-20 12:48:03 EDT
Okay, so local.te now only contains these two lines:

domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t);
setsebool -P httpd_can_network_connect=1;

I did 'make load' in the policy directory but got the following error:

domains/misc/local.te:7:ERROR 'syntax error' at token 'setsebool' on line 6451:
;
setsebool -P httpd_can_network_connect=1;
/usr/bin/checkpolicy:  error(s) encountered while parsing configuration
make: *** [/etc/selinux/targeted/policy/policy.19] Error 1
Comment 16 Stephen Smalley 2005-10-20 12:54:23 EDT
setsebool is a utility (a user command), not a policy statement.
Dan meant for you to run it, not add it to the local.te file.
By passing the -P, the new boolean value will be saved (in a "booleans" file
elsewhere in the policy tree) for reboots as well.
Comment 17 Darren Brierton 2005-10-20 13:02:54 EDT
Re comment #16, thanks!

So, local.te now simply contains:

domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t);

I've done 'make load' in the policy directory, setenforce was already set to 1
from the previous round of changes. I'm assuming that's enough to have loaded
the new policy. I'll leave it for ten minutes or so and then attach my audit.log.
Comment 18 Darren Brierton 2005-10-20 13:26:44 EDT
Okay, the new policy has been running for about 25 minutes. I can definitely
confirm that spam filtering is NOT working. Attaching audit.log.
Comment 19 Darren Brierton 2005-10-20 13:45:22 EDT
Created attachment 120201 [details]
bzip2 of /var/log/audit/audit.log

audit.log is huge (6.6MB)! How come it isn't rotated like the rest of the log
files? Anyway, I've attached a bzip2ed version (299KB).
Comment 20 Alexandre Oliva 2005-10-22 11:54:47 EDT
Dunno whether this is the same problem that hit me on my development install,
but I had to add the following to my local.te to get spamd to even start:

allow spamd_t default_t:lnk_file read;
allow spamd_t port_t:udp_socket name_bind;

(it's the latter that actually fixes the problem, I'm pretty sure; the former is
probably just a symptom of my having a soft-link for my ~/.spamassassin, but it
would be nice to have that into the policy as well)
Comment 21 Darren Brierton 2005-10-24 07:45:28 EDT
Following a chat on IRC with Daniel Walsh I modified
/etc/selinux/targeted/src/policy/domains/misc/local.te to contain just this line:

r_dir_file(postfix_local_t, etc_mail_t);

and this has got spamassassin working 90%. However, Bayesian filtering is still
not working. For this to work, spamd needs to be able to read the Bayesian data
which is in ~/.spamassassin. The permissions on ~/.spamassassin are as follows:

$ ls -ldZ .spamassassin/
drwx------  darren   darren   user_u:object_r:user_home_t      .spamassassin/

$ ls -lZ .spamassassin/
-rw-------  darren   darren   user_u:object_r:user_home_t      auto-whitelist
-rw-------  darren   darren   user_u:object_r:user_home_t      bayes_seen
-rw-------  darren   darren   user_u:object_r:user_home_t      bayes_toks
-rw-rw-r--  darren   darren   user_u:object_r:user_home_t      old_bayes_seen
-rw-rw-r--  darren   darren   user_u:object_r:user_home_t      old_bayes_toks
-rw-r--r--  darren   darren   user_u:object_r:user_home_t      user_prefs

Since the selinux policy update, and since the modification to local.te, I am
seeing messages in /var/log/maillog like this:

Oct 21 16:46:35 excession spamd[2247]: connection from excession.dzr [127.0.0.1]
at port 40689
Oct 21 16:46:35 excession spamd[2247]: info: setuid to darren succeeded
Oct 21 16:46:35 excession spamd[2247]: Creating default_prefs
[/home/darren/.spamassassin/user_prefs]
Oct 21 16:46:35 excession spamd[2247]: Cannot write to
/home/darren/.spamassassin/user_prefs: Permission denied
Oct 21 16:46:35 excession spamd[2247]: Couldn't create readable default_prefs
for [/home/darren/.spamassassin/user_prefs]
Oct 21 16:46:36 excession spamd[2247]: processing message
<9b9801c5d652$11c16042$ce842dc8@frwpik1> for darren:500.
Oct 21 16:46:36 excession spamd[2247]: identified spam (5.6/5.0) for darren:500
in 0.2 seconds, 1670 bytes.
Oct 21 16:46:36 excession spamd[2247]: result: Y  5 -
DATE_IN_FUTURE_96_XX,FORGED_RCVD_HELO,INVALID_DATE,MSGID_DOLLARS,NO_OBLIGATION,NO_REAL_NAME,RCVD_BY_IP
scantime=0.2,size=1670,mid=<9b9801c5d652$11c16042$ce842dc8@frwpik1>,autolearn=no

Note that the last line is the spamassassin tests. This should include a
Bayesian score of the form BAYES_## but as you can see it doesn't because the
spamd could not access the Bayesian data in ~/.spamassassin.

If we compare a message from /var/log/maillog.1 from before the selinux policy
update we can see:

Oct 17 11:35:14 excession spamd[2491]: connection from excession.dzr [127.0.0.1]
at port 53984
Oct 17 11:35:14 excession spamd[2491]: info: setuid to darren succeeded
Oct 17 11:35:16 excession spamd[2491]: processing message
<57626485.0.16Oct2005224523-osrs-resellers-1041@mp.opensrs.net> for darren:500.
Oct 17 11:35:33 excession spamd[2491]: clean message (-3.4/5.0) for darren:500
in 19.1 seconds, 3161 bytes.
Oct 17 11:35:33 excession spamd[2491]: result: . -3 - AWL,BAYES_00
scantime=19.1,size=3161,mid=<57626485.0.16Oct2005224523-osrs-resellers-1041@mp.opensrs.net>,bayes=4.05883510135041e-09,autolearn=ham

I believe that this is an instance of the messages being written to audit.log
regarding this issue:

type=AVC msg=audit(1130150210.212:16477): avc:  denied  { search } for  pid=2247
comm="spamd" name="/" dev=hda5 ino=2 scontext=system_u:system_r:spamd_t
tcontext=system_u:object_r:home_root_t tclass=dir
type=SYSCALL msg=audit(1130150210.212:16477): arch=40000003 syscall=195
success=no exit=-13 a0=a419878 a1=97520c8 a2=9b7ff4 a3=a419878 items=1 pid=2247
auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500
comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1130150210.212:16477):  cwd="/"
type=PATH msg=audit(1130150210.212:16477): item=0
name="/home/darren/.spamassassin/user_prefs" flags=1  inode=2 dev=03:05
mode=040755 ouid=0 ogid=0 rdev=00:00

Obviously if I can provide more information please let me know.
Comment 22 Daniel Walsh 2005-10-24 09:49:38 EDT
Alexandre Oliva (oliva@lsd.ic.unicamp.br)

The following looks like a labeling problem if this is indead a link in your
homedir it should be labeled user_home_t.
allow spamd_t default_t:lnk_file read;

What port is it trying to connect to?
allow spamd_t port_t:udp_socket name_bind;

I will allow spamd to seach home_root_t.
Comment 23 Darren Brierton 2005-10-24 10:06:53 EDT
(In reply to comment #22)
> I will allow spamd to seach home_root_t.

Excellent. What should I add as a temporary workaround to local.te until the
next update?
Comment 24 Alexandre Oliva 2005-10-24 13:23:25 EDT
My ~/.spamassassin is a link pointing outside my home dir, and even though /home
(another link) was properly labeled, the directory it pointed to wasn't.  Or
something along these lines.  Relabeling the pointed-to directory as home_root_t
and adding the following line to local.te (there you go, Darren :-) enabled it
to work again.

allow spamd_t home_root_t:dir search;


As for the port it's binding to, I've no idea of how to tell.  I'd think it's
for DNS resolution, for the several live blocking databases.  This is what gets
logged in audit.log:

type=AVC msg=audit(1129838891.100:70): avc:  denied  { name_bind } for  pid=2331
comm="spamd" src=21875 scontext=system_u:system_r:spamd_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1129838891.100:70): arch=40000003 syscall=102 success=no
exit=-13 a0=2 a1=bfff6b90 a2=745b500 a3=10 items=0 pid=2331 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd"
exe="/usr/bin/perl"
type=SOCKADDR msg=audit(1129838891.100:70): saddr=02005573000000000000000000000000
type=SOCKETCALL msg=audit(1129838891.100:70): nargs=3 a0=6 a1=8ba0a38 a2=10
Comment 25 Darren Brierton 2005-10-24 15:34:01 EDT
Thanks, Alexandre. Unfortunately adding

allow spamd_t home_root_t:dir search;

to my local.te didn't work. After a suggestion from dwalsh on IRC I also tried

r_dir_file(spamd_t, user_home_t);

and that didn't do the trick either. I also tried both, and that too was no
help. This is what is being written to /var/log/maillog:

Oct 24 20:26:56 excession spamd[2248]: connection from excession.dzr [127.0.0.1]
at port 40421
Oct 24 20:26:56 excession spamd[2248]: info: setuid to darren succeeded
Oct 24 20:26:56 excession spamd[2248]: Creating default_prefs
[/home/darren/.spamassassin/user_prefs]
Oct 24 20:26:56 excession spamd[2248]: Cannot write to
/home/darren/.spamassassin/user_prefs: Permission denied
Oct 24 20:26:56 excession spamd[2248]: Couldn't create readable default_prefs
for [/home/darren/.spamassassin/user_prefs]
Oct 24 20:26:56 excession spamd[2248]: processing message
<1130181863.9090.0.camel@excession.dzr> for darren:500.
Oct 24 20:26:57 excession spamd[2248]: clean message (0.0/5.0) for darren:500 in
0.2 seconds, 1862 bytes.
Oct 24 20:26:57 excession spamd[2248]: result: .  0 - RCVD_BY_IP
scantime=0.2,size=1862,mid=<1130181863.9090.0.camel@excession.dzr>,autolearn=failed
Oct 24 20:26:57 excession postfix/local[13903]: BD61B431FB4:
to=<darren@localhost.excession.dzr>, orig_to=<darren@localhost>, relay=local,
delay=1, status=sent (delivered to command: IFS=' ' && exec /usr/bin/procmail
-f- || exit 75 #darren)

However, I can't see anything being written to audit.log about this now (I just
watched what happened when a new mail message came in using "tail -f
/var/log/audit/audit.log"). Given that spamd is running as setuid darren when it
runs I don't think it is a permissions problem (of the chmod variety), but
surely if it was an selinux issue something would have been written to
audit.log. I'm stumped.
Comment 26 Darren Brierton 2005-10-24 17:12:19 EDT
Adding

allow spamd_t user_home_dir_t:dir { getattr search };

to local.te worked! Thanks to dwalsh on IRC for the tip.
Comment 27 Darren Brierton 2005-10-24 17:23:19 EDT
Sorry, but I've just realised something else. For Bayesian filtering spamd needs
to *read* ~/.spamassassin, which it now can. But for Bayesian autolearning it
also needs to be able to *write* to ~/.spamassassin.

This (from /var/log/maillog) shows Bayesian analysis working (note BAYES_00 in
the last line) but autolearning still failing (4th line and end of last line).

Oct 24 22:21:24 excession spamd[2247]: connection from excession.dzr [127.0.0.1]
at port 40860
Oct 24 22:21:24 excession spamd[2247]: info: setuid to darren succeeded
Oct 24 22:21:24 excession spamd[2247]: processing message
<435D501B.4030907@cha.forthnet.gr> for darren:500.
Oct 24 22:21:24 excession spamd[2247]: cannot write to
/home/darren/.spamassassin/bayes_journal, Bayes db update ignored: Permission denied
Oct 24 22:21:24 excession spamd[2247]: clean message (-2.4/5.0) for darren:500
in 0.4 seconds, 4748 bytes.
Oct 24 22:21:24 excession spamd[2247]: result: . -2 -
BAYES_00,MISSING_HEADERS,RCVD_BY_IP
scantime=0.4,size=4748,mid=<435D501B.4030907@cha.forthnet.gr>,bayes=0,autolearn=failed
Comment 28 Darren Brierton 2005-10-31 17:51:38 EST
I just upgraded to the latest from updates-released:

$ rpm -qa | grep selinux-policy | sort
selinux-policy-strict-1.27.1-2.11
selinux-policy-strict-sources-1.27.1-2.11
selinux-policy-targeted-1.27.1-2.11
selinux-policy-targeted-sources-1.27.1-2.11

in order to check whether they resolved the problems in this bug report I
commented out the contents of my local.te and did make load in the policy
directory. Bayesian spam filtering and auto-learning as described in comments
#21 to #27 is still not working.
Comment 29 Nicolas Mailhot 2005-11-12 13:44:01 EST
BTW the bug #172088 documents another procmail/spamassassin reicipe using spamc
instead of the old spamassassin command
Comment 30 Habig, Alec 2005-11-30 20:29:42 EST
Just checked with the recently released selinux-policy-targeted-1.27.1-2.14, and
spamd is still not allowed to write to my ~/.spamassassin directory.  Running
with enforce=0 lets things work, but that's a pretty draconian workaround.
Comment 31 Habig, Alec 2005-11-30 21:03:38 EST
Apologies - when used in conjunction with the new kernel (2.6.14-1.1644_FC4smp),
things _do_ work right.  Selinux is enforcing and spamd is happy.

Note You need to log in before you can comment on or make changes to this bug.