Description of problem:

selinux denies spamd access to sh, which it needs to run the tools needed to ocr
the spam image.

Version-Release number of selected component (if applicable):

selinux-policy-targeted-1.27.1-2.28
Spamassassin 3.1.7
FuzzyOcr 3.4.2

How reproducible:

always

Steps to Reproduce:
1.Install the FuzzyOcr plugin (http://fuzzyocr.own-hero.net/wiki)
2.try a sample spam image email with spamassassin -t sample.eml  It works
3.try the same email with spamd: spamc -r < sample.eml  The plugin starts but
does nothing.

Ok, there has to be a more straightforward way to test this, but this is how I
found it :)
  
Actual results:

This plugin fail silently from spamd, but work fine from the command line 

Expected results:

Should run the same for the daemon or the user.

Additional info:

The audit message:

type=PATH msg=audit(1165415409.901:53683): item=0 name="/bin/sh" parent=0
dev=00:00 mode=00 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1165415409.913:53684): avc:  denied  { read } for  pid=6941
comm="spamd" name="sh" dev=sda1 ino=219076 scontext=root:system_r:spamd_t
tcontext=system_u:object_r:bin_t tclass=lnk_file

The line of perl in the plugin which seems to be triggering it:

 $imgdir = Mail::SpamAssassin::Util::secure_tmpdir() unless ($imgdir);

which opens the file using

  sysopen($tmpfile, $reportfile, O_RDWR|O_CREAT|O_EXCL, 0600)

I'm somewhat suprised that perl would need sh here, but it certainly does later
when it spawns some image manipulation tools to try the OCR on the spam image,
so the error could be later if the intervening debug log messages are being
gobbled somewhere.

Disabling selinux for spamd does fix the problem:

  setsebool -P spamd_disable_trans 1 

How could I test out simply allowing spamd to run sh and verify that this is the
only problem?