Greetings;
Just recovering from a drive failure, and just now managed to get enough perl deps installed to run spamassassin.
I modified the spamassassin script in /etc/init.d to run it as the same user that fetches the mail, also fixed the spamassassin in /etc/sysconfig to match, and according to htop, the spamd's are running as that user.
But, selinux is still having a cow for every incoming message. ========= Source Context: system_u:system_r:spamd_t:s0 Target Context: system_u:object_r:home_root_t:s0 Target Objects: ./user_prefs [ file ] ===temp end of snip
From that, here is that file:
[root@coyote .spamassassin]# ls -l user_prefs -rw-r--r-- 1 gene gene 1164 2006-01-16 13:45 user_prefs [root@coyote .spamassassin]# ls -l --context user_prefs -rw-r--r-- gene gene system_u:object_r:home_root_t:s0 user_prefs
===back to troubleshooter output
host=coyote.coyote.den type=AVC msg=audit(1227116423.127:797): avc: denied { write } for pid=7118 comm="spamd" name="user_prefs" dev=sda3 ino=74942440 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=file
host=coyote.coyote.den type=SYSCALL msg=audit(1227116423.127:797): arch=40000003 syscall=5 success=no exit=-13 a0=9a83590 a1=8241 a2=1b6 a3=8241 items=0 ppid=7116 pid=7118 auid=0 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=1 comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 key=(null) ========= Secondary Q: when are we going to be able to copy & paste from the selinuxtroubleshooter screen and preserve the ^%$*^%$( formatting?
I have performed the troubleshooter recommended fix:
setsebool -P spamd_enable_home_dirs=1
and restarted spamassassin several times.
Perms or context problem with the /home dirs?
A bug?
Or I need to do an autorelabel?
The /home dirs, FWIW, were copied from another drive by mc & then 'chown -R user:user' when the copy was finished which may not have been the correct thing to do FAIK. But it was the only way I could preserve an email corpus that is in the 10Gb area for size.
There are no entries for spamassassin or spamd in /etc/group that I could use to make that file a member of.
Fix please?
Thanks.
On Wed, 19 Nov 2008 13:00:18 -0500 Gene Heskett gene.heskett@verizon.net wrote:
Greetings;
Just recovering from a drive failure, and just now managed to get enough perl deps installed to run spamassassin.
I modified the spamassassin script in /etc/init.d to run it as the same user that fetches the mail, also fixed the spamassassin in /etc/sysconfig to match, and according to htop, the spamd's are running as that user.
But, selinux is still having a cow for every incoming message.
Source Context: system_u:system_r:spamd_t:s0 Target Context: system_u:object_r:home_root_t:s0 Target Objects: ./user_prefs [ file ] ===temp end of snip
From that, here is that file:
[root@coyote .spamassassin]# ls -l user_prefs -rw-r--r-- 1 gene gene 1164 2006-01-16 13:45 user_prefs [root@coyote .spamassassin]# ls -l --context user_prefs -rw-r--r-- gene gene system_u:object_r:home_root_t:s0 user_prefs
===back to troubleshooter output
host=coyote.coyote.den type=AVC msg=audit(1227116423.127:797): avc: denied { write } for pid=7118 comm="spamd" name="user_prefs" dev=sda3 ino=74942440 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=file
host=coyote.coyote.den type=SYSCALL msg=audit(1227116423.127:797): arch=40000003 syscall=5 success=no exit=-13 a0=9a83590 a1=8241 a2=1b6 a3=8241 items=0 ppid=7116 pid=7118 auid=0 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=1 comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 key=(null) ========= Secondary Q: when are we going to be able to copy & paste from the selinuxtroubleshooter screen and preserve the ^%$*^%$( formatting?
I have performed the troubleshooter recommended fix:
setsebool -P spamd_enable_home_dirs=1
and restarted spamassassin several times.
Perms or context problem with the /home dirs?
A bug?
Or I need to do an autorelabel?
The /home dirs, FWIW, were copied from another drive by mc & then 'chown -R user:user' when the copy was finished which may not have been the correct thing to do FAIK. But it was the only way I could preserve an email corpus that is in the 10Gb area for size.
There are no entries for spamassassin or spamd in /etc/group that I could use to make that file a member of.
Fix please?
Regular unix usernames and groups will make little difference to SELinux. What you need is the right SELinux labelling for the files.
Try this: # restorecon -RF /home/*/.spamassassin/
On F9 at least, I believe ~/.spamassassin should have context type user_spamassassin_home_t rather than home_root_t which is what you seem to have now.
If this fixes things for you, it's likely that there are other similar issues that will need fixing up, and doing a relabel will be a good idea when you can spare the time.
Paul.
On Wednesday 19 November 2008, Paul Howarth wrote:
On Wed, 19 Nov 2008 13:00:18 -0500
Gene Heskett gene.heskett@verizon.net wrote:
Greetings;
Just recovering from a drive failure, and just now managed to get enough perl deps installed to run spamassassin.
I modified the spamassassin script in /etc/init.d to run it as the same user that fetches the mail, also fixed the spamassassin in /etc/sysconfig to match, and according to htop, the spamd's are running as that user.
But, selinux is still having a cow for every incoming message.
Source Context: system_u:system_r:spamd_t:s0 Target Context: system_u:object_r:home_root_t:s0 Target Objects: ./user_prefs [ file ] ===temp end of snip
From that, here is that file:
[root@coyote .spamassassin]# ls -l user_prefs -rw-r--r-- 1 gene gene 1164 2006-01-16 13:45 user_prefs [root@coyote .spamassassin]# ls -l --context user_prefs -rw-r--r-- gene gene system_u:object_r:home_root_t:s0 user_prefs
===back to troubleshooter output
host=coyote.coyote.den type=AVC msg=audit(1227116423.127:797): avc: denied { write } for pid=7118 comm="spamd" name="user_prefs" dev=sda3 ino=74942440 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=file
host=coyote.coyote.den type=SYSCALL msg=audit(1227116423.127:797): arch=40000003 syscall=5 success=no exit=-13 a0=9a83590 a1=8241 a2=1b6 a3=8241 items=0 ppid=7116 pid=7118 auid=0 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=1 comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 key=(null) ========= Secondary Q: when are we going to be able to copy & paste from the selinuxtroubleshooter screen and preserve the ^%$*^%$( formatting?
I have performed the troubleshooter recommended fix:
setsebool -P spamd_enable_home_dirs=1
and restarted spamassassin several times.
Perms or context problem with the /home dirs?
A bug?
Or I need to do an autorelabel?
The /home dirs, FWIW, were copied from another drive by mc & then 'chown -R user:user' when the copy was finished which may not have been the correct thing to do FAIK. But it was the only way I could preserve an email corpus that is in the 10Gb area for size.
There are no entries for spamassassin or spamd in /etc/group that I could use to make that file a member of.
Fix please?
Regular unix usernames and groups will make little difference to SELinux. What you need is the right SELinux labelling for the files.
Try this: # restorecon -RF /home/*/.spamassassin/
I can do this right now, hang on. Quick, less than a second. Now we wait to see if it throw up another icon to match the incoming mail beep. Yes, it took nearly a minute after procmail.log showed it, for it to get here, and now another mail has arrived with no alert and denial.
Thanks Paul, and a big bow in your direction.
On F9 at least, I believe ~/.spamassassin should have context type user_spamassassin_home_t rather than home_root_t which is what you seem to have now.
If this fixes things for you, it's likely that there are other similar issues that will need fixing up, and doing a relabel will be a good idea when you can spare the time.
Paul.
I did a "touch /.autorelabel" about tuesday evening after one install, and it seemed to be ignored on the reboot. Is that not the correct method?
Thanks again.
On Wed, 19 Nov 2008 22:43:50 -0500 Gene Heskett gene.heskett@verizon.net wrote:
Try this: # restorecon -RF /home/*/.spamassassin/
I can do this right now, hang on. Quick, less than a second. Now we wait to see if it throw up another icon to match the incoming mail beep. Yes, it took nearly a minute after procmail.log showed it, for it to get here, and now another mail has arrived with no alert and denial.
Thanks Paul, and a big bow in your direction.
Thanks.
On F9 at least, I believe ~/.spamassassin should have context type user_spamassassin_home_t rather than home_root_t which is what you seem to have now.
If this fixes things for you, it's likely that there are other similar issues that will need fixing up, and doing a relabel will be a good idea when you can spare the time.
Paul.
I did a "touch /.autorelabel" about tuesday evening after one install, and it seemed to be ignored on the reboot. Is that not the correct method?
That is the correct method. Are you sure there wasn't a typo? If the file has been ignored, it should still be there now.
Paul.
selinux@lists.fedoraproject.org
-
Gene Heskett -
Paul Howarth