On Aug 18, 2010, at 17:01, Daniel B. Thurman wrote:
>>> node=(removed) type=AVC msg=audit(1282086325.907:81309): avc: denied {name_bind } for pid=23536 comm="spamassassin" src=32726 scontext=system_u:system_r:spamc_t:s0
>>> tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
>> It kind of depends in my view. Here the spamassassin client app tries to bind udp socket to port 32726.
I think it's a mistake to have the same limitations apply to both /usr/bin/spamc and /usr/bin/spamassassin, if that is really the case with the current policy.
ls -Z /usr/bin/spam*
-rwxr-xr-x. root root system_u:object_r:spamc_exec_t:s0 /usr/bin/spamassassin
-rwxr-xr-x. root root system_u:object_r:spamc_exec_t:s0 /usr/bin/spamc
-rwxr-xr-x. root root system_u:object_r:spamd_exec_t:s0 /usr/bin/spamd
/usr/bin/spamassassin is the all-in-one standalone version. It is normal for it to network freely and would need to have the permissions of both spamd and spamc combined.
/usr/bin/spamc on the other hand only needs to talk to spamd running on localhost tcp port 783 and nothing else, and spamd does all the real work.
For what it's worth, I use spamd/spamc and didn't have any issues with anything being denied in many, many years.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
