-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Arthur Dent wrote:
On Mon, Feb 02, 2009 at 07:01:16PM +0100, Dominick Grift wrote:
On second thought, no. I do not think spamd_t has access to user_pyzor_home_t.
sesearch --allow -s spamd_t | grep home | less
so i guess your custom module fixes that. consider filing a bug report for this issue.
Thanks for your help. I have not yet altered my new local policy, but I thought I would try a reboot to see if that had any affect...
Oh boy! A whole raft of denials...
This is the audit2allow result of this recent batch. It seems quite a lot to me!
require { type user_pyzor_home_t; type admin_home_t; type spamd_t; type procmail_t; class dir { read write add_name remove_name }; class file { read create ioctl write getattr unlink append }; }
#============= procmail_t ============== init_stream_connect_script(procmail_t)
This looks like you have some process running as initrc_t that procmail needs to talk to. If this is not a domain we have a confinement for this is fine.
#============= spamd_t ============== allow spamd_t admin_home_t:dir { read write add_name remove_name }; allow spamd_t admin_home_t:file { write getattr read create unlink ioctl append };
This is spamd creating stuff in the /root directory. Not sure if you want to actually allow this. Might want to setup the directory with properly lableing to allow spamd to write there. userdom_read_sysadm_home_content_files(spamd_t)
What directory?
You could setup labeling of
# semanage fcontext -a -t spamassassin_home_t '/root/.spamassassin(/.*)?' #restorecon -R -v /root
allow spamd_t user_pyzor_home_t:file { read getattr };
This should be allowed and should be reported as a bug.
What do you think?
Thanks again
Mark
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list