Marc Schwartz wrote:
After loading the updated modules, you'll need to do:
# restorecon -rv /var/dcc
Done and new mydcc policy installed:
# semodule -l amavis 1.0.4 clamav 1.0.1 dcc 1.0.0 myclamav 0.1.1 mydcc 0.1.6 mypostfix 0.1.0 mypyzor 0.2.1 myspamassassin 0.1.1 procmail 0.5.4 pyzor 1.0.1 razor 1.0.0
New avc's:
type=AVC msg=audit(1151269000.770:5837): avc: denied { search } for pid=23000 comm="dccproc" name="dcc" dev=dm-1 ino=58510 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir type=SYSCALL msg=audit(1151269000.770:5837): arch=40000003 syscall=12 success=yes exit=0 a0=bfdb1202 a1=0 a2=4891eff4 a3=37 items=1 pid=23000 auid=4294967295 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc" exe="/usr/local/bin/dccproc" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1151269000.770:5837): cwd="/" type=PATH msg=audit(1151269000.770:5837): item=0 name="/var/dcc" inode=58510 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:dcc_var_t:s0
dccproc is still running in the spamd_t domain; for some reason the domain transition hasn't happened.
Can you check that the dccproc being invoked by spamassassin is the one in /usr/local/bin and that its context type is dcc_client_exec_t?
Paul.