Justin Willmert wrote:
I am hoping somebody can help me solve a problem I am having with procmail and spamassassin (specifically spamd). When spamassassin has marked a message as spam, it gets sorted to a Junk folder, but the problem is that it is owned by root:mail when it should be owned by the user. When this happens, dovecot will not serve the email to the user. I sort other emails into folders with simple matching rules and those work fine. Spamassassin is the only rule that is piped out to a program.
Here is the relevant portion my procmailrc file:
DROPPRIV=yes # Make this run as a normal user. If you need # root privileges for something, do it before # this line. # Send mail through spamassassin :0fw | spamc -u $LOGNAME
# Now that we've tagged the spam, put in the appropriate folder :0
- ^X-Spam-Status: Yes
.Junk/
I've tried taking the -u $LOGNAME portion out too and that doesn't work. Following is a maillog sample.
Jan 29 17:47:11 netserv sendmail[19847]: k0TNlAig019847: Milter add: header: X-Virus-Scanned: ClamAV 0.88/1257/Sun Jan 29 09:15:47 2006 on mydomain.com Jan 29 17:47:11 netserv sendmail[19847]: k0TNlAig019847: Milter add: header: X-Virus-Status: Clean Jan 29 17:47:11 netserv spamd[19654]: connection from mydomain.com [127.0.0.1] at port 57905 Jan 29 17:47:11 netserv spamd[19654]: handle_user: unable to find user 'justin'! Jan 29 17:47:11 netserv spamd[19654]: Still running as root: user not specified with -u, not found, or set to root. Fall back to nobody. Jan 29 17:47:11 netserv spamd[19654]: processing message BAY107-F2792E57045186E9EED3A038A160@phx.gbl for justin:99. Jan 29 17:47:11 netserv spamd[19654]: cannot write to /etc/mail/bayes/bayes_journal, Bayes db update ignored: Permission denied Jan 29 17:47:13 netserv spamd[19654]: clean message (1.7/5.0) for justin:99 in 1.5 seconds, 1076 bytes. Jan 29 17:47:13 netserv spamd[19654]: result: . 1 - BAYES_50,DNS_FROM_RFC_POST,MSGID_FROM_MTA_HEADER
scantime=1.5,size=1076,mid=BAY107-F2792E57045186E9EED3A038A160@phx.gbl,bayes=0.499999999735837,autolearn=no
Jan 29 17:47:13 netserv sendmail[19849]: k0TNlAig019847: to=justin@mydomain.com, delay=00:00:02, xdelay=00:00:02, mailer=local, pri=30995, dsn=2.0.0, stat=Sent
As you can see, I've also got a problem with not being able to access the bayes_journal. I've put it in it's own directory and made them owned by nobody:staff and still nothing. Anyway, here is my local.cf file:
# These values can be overridden by editing ~/.spamassassin/user_prefs.cf # (see spamassassin(1) for details)
# How many hits before a message is considered spam. The lower the number, the # more sensitive it is. required_hits 5
# Encapsulate spam in an attachment (0=No, 1=Yes in message/rfc822, # 2=Yes in text/plain) report_safe 0
# Text to prepend to subject of spam rewrite_header Subject [SPAM]
# Enable the Bayes System use_bayes 1
# Enable Bayes auto-learning bayes_auto_learn 1
# Mail using languages used in these country codes will not be marked as being # possibly spam in a foreign language. ok_languages en
I'd be happy to send along any other information you need. Thanks for help in advance.
Justin Willmert
I'm cc-ing this to the fedora-selinux-list. I think some of the problems may be applicable there.
OK, after some more testing, when I disable SELinux, many of the errors go away. First of all, I get rid of the error message saying user can not be found and with it the 'still running as root' error. Second, it is able to access the bayes_journal file (as long as normal unix permissions are right, which I've figured out). So I guess the problem is an SELinux issue which I can't solve. I'd attach some avc error messages, but I can't seem to find any. I've looked in maillog, secure, and messages, but nothing.
I'm cc-ing this to the fedora-selinux-list. I think some of the problems may be applicable there.
OK, after some more testing, when I disable SELinux, many of the errors go away. First of all, I get rid of the error message saying user can not be found and with it the 'still running as root' error. Second, it is able to access the bayes_journal file (as long as normal unix permissions are right, which I've figured out). So I guess the problem is an SELinux issue which I can't solve. I'd attach some avc error messages, but I can't seem to find any. I've looked in maillog, secure, and messages, but nothing.
Have you looked in the audit log, where all such messages are usually found ? /var/log/audit.log
Ivan Gyurdiev wrote:
I'm cc-ing this to the fedora-selinux-list. I think some of the problems may be applicable there.
OK, after some more testing, when I disable SELinux, many of the errors go away. First of all, I get rid of the error message saying user can not be found and with it the 'still running as root' error. Second, it is able to access the bayes_journal file (as long as normal unix permissions are right, which I've figured out). So I guess the problem is an SELinux issue which I can't solve. I'd attach some avc error messages, but I can't seem to find any. I've looked in maillog, secure, and messages, but nothing.
Have you looked in the audit log, where all such messages are usually found ? /var/log/audit.log
Below is what showed up in audit/audit.log when I sent a message through spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I have to deal with quite often that I haven't been able to learn how to use...it's so foreign to me. I've never looked in audit.log before: the avc messages used to show up in messages, but now as far back as my logs go, I don't have a single avc message. This all looks like jibberish to me, so I need your guy's help.
Thanks, Justin
type=AVC msg=audit(1138596151.681:104174): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596151.681:104174): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596151.681:104174): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596151.681:104174): nargs=3 a0=7 a1=9b1fe80 a2=10 type=AVC msg=audit(1138596153.220:104175): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596153.220:104175): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596153.220:104175): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596153.220:104175): nargs=3 a0=7 a1=9b6a6f0 a2=10 type=AVC msg=audit(1138596160.388:104176): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596160.388:104176): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596160.388:104176): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596160.388:104176): nargs=3 a0=7 a1=9b20050 a2=10 type=AVC msg=audit(1138596164.032:104177): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596164.032:104177): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596164.032:104177): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596164.032:104177): nargs=3 a0=7 a1=9b84af0 a2=10
On Sun, 2006-01-29 at 22:52 -0600, Justin Willmert wrote:
Ivan Gyurdiev wrote:
I'm cc-ing this to the fedora-selinux-list. I think some of the problems may be applicable there.
OK, after some more testing, when I disable SELinux, many of the errors go away. First of all, I get rid of the error message saying user can not be found and with it the 'still running as root' error. Second, it is able to access the bayes_journal file (as long as normal unix permissions are right, which I've figured out). So I guess the problem is an SELinux issue which I can't solve. I'd attach some avc error messages, but I can't seem to find any. I've looked in maillog, secure, and messages, but nothing.
Have you looked in the audit log, where all such messages are usually found ? /var/log/audit.log
Below is what showed up in audit/audit.log when I sent a message through spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I have to deal with quite often that I haven't been able to learn how to use...it's so foreign to me. I've never looked in audit.log before: the avc messages used to show up in messages, but now as far back as my logs go, I don't have a single avc message. This all looks like jibberish to me, so I need your guy's help.
Thanks, Justin
type=AVC msg=audit(1138596151.681:104174): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596151.681:104174): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596151.681:104174): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596151.681:104174): nargs=3 a0=7 a1=9b1fe80 a2=10 type=AVC msg=audit(1138596153.220:104175): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596153.220:104175): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596153.220:104175): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596153.220:104175): nargs=3 a0=7 a1=9b6a6f0 a2=10 type=AVC msg=audit(1138596160.388:104176): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596160.388:104176): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596160.388:104176): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596160.388:104176): nargs=3 a0=7 a1=9b20050 a2=10 type=AVC msg=audit(1138596164.032:104177): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596164.032:104177): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596164.032:104177): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596164.032:104177): nargs=3 a0=7 a1=9b84af0 a2=10
Are you using LDAP for authentication or to handle mail accounts?
Paul.
Paul Howarth wrote:
On Sun, 2006-01-29 at 22:52 -0600, Justin Willmert wrote:
Ivan Gyurdiev wrote:
I'm cc-ing this to the fedora-selinux-list. I think some of the problems may be applicable there.
OK, after some more testing, when I disable SELinux, many of the errors go away. First of all, I get rid of the error message saying user can not be found and with it the 'still running as root' error. Second, it is able to access the bayes_journal file (as long as normal unix permissions are right, which I've figured out). So I guess the problem is an SELinux issue which I can't solve. I'd attach some avc error messages, but I can't seem to find any. I've looked in maillog, secure, and messages, but nothing.
Have you looked in the audit log, where all such messages are usually found ? /var/log/audit.log
Below is what showed up in audit/audit.log when I sent a message through spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I have to deal with quite often that I haven't been able to learn how to use...it's so foreign to me. I've never looked in audit.log before: the avc messages used to show up in messages, but now as far back as my logs go, I don't have a single avc message. This all looks like jibberish to me, so I need your guy's help.
Thanks, Justin
type=AVC msg=audit(1138596151.681:104174): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596151.681:104174): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596151.681:104174): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596151.681:104174): nargs=3 a0=7 a1=9b1fe80 a2=10 type=AVC msg=audit(1138596153.220:104175): avc: denied { name_connect } for pid=23796 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596153.220:104175): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23796 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596153.220:104175): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596153.220:104175): nargs=3 a0=7 a1=9b6a6f0 a2=10 type=AVC msg=audit(1138596160.388:104176): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596160.388:104176): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596160.388:104176): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596160.388:104176): nargs=3 a0=7 a1=9b20050 a2=10 type=AVC msg=audit(1138596164.032:104177): avc: denied { name_connect } for pid=23797 comm="spamd" dest=389 scontext=root:system_r:spamd_t tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket type=SYSCALL msg=audit(1138596164.032:104177): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7 items=0 pid=23797 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99 egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl" type=SOCKADDR msg=audit(1138596164.032:104177): saddr=02000185C0A801940000000000000000 type=SOCKETCALL msg=audit(1138596164.032:104177): nargs=3 a0=7 a1=9b84af0 a2=10Are you using LDAP for authentication or to handle mail accounts?
Paul.
No, I am not using LDAP in spamassassin itself (there are ldap arguments to spamd and I'm not using those), but my system uses LDAP authentication through nsswitch/pam (whatever the distinction is). Does spamd need to know my ldap server's information?
I believe I found a temporary work around for the bayes files: I put them in a non-standard location (/etc/mail/bayes/) because I wanted a system-wide database (some users don't get enough spam to warrant their own database). I found if I set /etc/mail/bayes/ to user_home_dir_t and /etc/mail/bayes/* to user_home_t that the denied messages for files are gone (if I'm reading the logs right). I don't see the file denial messages in the log output I put above, but they are in audit.log and in the latest test, they aren't there so I'm hoping I'm looking into all of this right. If you want me to confirm all of this, I can reset the directory context and do some tests, then set up the directory context again and compare that result, somebody just has to ask. Now I've just got to solve the LDAP messages. I'll try to look into this a bit, but I'm probably going to need the help, so thanks to all those who take time to reply.
Justin
I said I'd post my final results, so here they are. All these problems are describing spamd and not the spamassassin program on FC4. The problems only affect spamd because it is subject to selinux policy effects where spamassassin (run by a user) isn't (at least in the targeted policy).
My first problem was with emails being owned by root instead of the correct user. I am using /etc/procmailrc rather than ~/.procmailrc, so it would by default be under root permissions. I added the line 'DROPPRIV=yes' to make it have user permissions instead, but I mistyped it. It should be 'DROPPRIVS=yes'. *Notice the added S*. That was all there was to that problem. Human error.
Next, I set up spamassassin to share a common bayes database. Even with nobody(99) owning it (that's what spamassassin would setuid to after failing to setuid to the user. More on that below...), I still couldn't write to the database. After looking through the selinux policy source files for spamassassin (you can surprisingly learn a lot just by looking through those files...), I found that the bayes files should probably have a user_home_t context, and the folder they reside in, a context of user_home_dir_t (which makes sense considering they're normally found in a user's home directory). After I had set /etc/mail/bayes/ (the folder I chose to house my bayes files) and it's contents to those contexts, I got rid of that problem.
Now for the user problems. All the users on my system are setup in an LDAP directory. My system uses nsswitch.conf mechanisms (set with the authconfig utility), so when spamd went to connect to the ldap server (indirectly through normal linux authentication libraries which behind the scenes connect to the ldap server. Programmers should understand this logic.), selinux would deny access because spamd doesn't have ldap_port_t permissions (or in layman's terms, spamd wasn't allowed to connect to any port but tcp port 783 which is spamd's command port). As of selinux-policy-targeted-1.27.1-2.16, there isn't a fix, but Dan Walsh has told me that he has put it in the rawhide and I've posted a bugzilla report about it, so there should be a fix soon. A perfectly OK temporary fix is to just use the spamassassin executable in your procmail scripts rather than using spamc to communicate to spamd. That's what I'm doing right now and it is working fine (with some performance loss because of program load/unload times, etc).
Thanks to all those who have helped. Justin Willmert
selinux@lists.fedoraproject.org
-
Ivan Gyurdiev -
Justin Willmert -
Paul Howarth