Bug 4139 - spamd fails to start - dccifd
Summary: spamd fails to start - dccifd
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.0.2
Hardware: Other other
: P3 minor
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-15 09:59 UTC by Dallas Engelken
Modified: 2006-04-15 20:32 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dallas Engelken 2005-02-15 09:59:37 UTC 
okay.. here is the situation.  yes, its going to be rare, but it should be
handled more gracefully.

/tmp is 0755... 
dccifd is ran with a non-root user

running spamd causes a dccifd check even if use_dcc 0 is set... dccifd sigpipes
and spamd exits..

[root@localhost /]# ls -lad /tmp
drwxr-xr-x  21 root root 4096 Feb 16 01:55 /tmp

[root@localhost /]# spamd -D >/dev/null 2>&1
[root@localhost /]# STATUS=$?
[root@localhost /]# echo $STATUS
141

the obvious solution is /tmp should be 777 and +t, but there are cases where
/tmp is not writable by users...  

strace shows the SIGPIPE

connect(8, {sa_family=AF_FILE, path="/var/dcc/dccifd.sock"}, 110) = 0
write(8, "header\n", 7)                 = 7
write(8, "0.0.0.0\n", 8)                = 8
write(8, "\n", 1)                       = 1
write(8, "\n", 1)                       = 1
write(8, "unknown\r\n", 9)              = 9
write(8, "\n", 1)                       = 1
write(8, "From: ignore@compiling.spamassas"..., 1443) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++


[root@localhost dcc]# ls -la /var/dcc/dccifd.sock
srw-rw-rw-  1 nobody nobody 0 Feb 16 01:58 /var/dcc/dccifd.sock

as you can see, the dccifd.sock is readable by spamd,  but dccifd must need /tmp
even though there is nothing in /tmp that is dccifd related.   As soon as I 

# chmod 777 /tmp
# chmod +t /tmp

spamd is fine...  should spamd honor use_dcc 0 in startup in checking the dccifd
socket?

also, i have yet to test the latest trunk to see if this is an issue or not...
Comment 1 Dallas Engelken 2005-02-15 10:08:07 UTC 
actually this appears to be spamd relying on /tmp, not dccifd since it appears
to function fine without a writable /tmp.    

It doesnt matter if spamd is ran with the -u flag or not, as it appears to drop
privledges to pipe out to dccifd anyways...
Comment 2 Sidney Markowitz 2006-04-16 03:32:54 UTC 
The temp file written by SpamAssassin is in a directory found using
File::Spec->tmpdir() which is documented as

"Returns a string representation of the first writable directory from a list of
possible temporary directories. Returns the current directory if no writable
temporary directories are found. The list of directories checked depends on the
platform; e.g. File::Spec::Unix checks $ENV{TMPDIR} (unless taint is on) and /tmp"

As far as I can tell this depends on File::Spec->tmpdir working correctly, which
may depend on /tmp having the correct permissions or TMPDIR being set correctly,
or whatever else is needed on other platforms. But this is external to
SpamAssassin, so I'm closing this as WONTFIX.