Bug 3441 - spamc segfaults when -u is used
Summary: spamc segfaults when -u is used
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 critical
Target Milestone: 3.0.0
Assignee: Malte S. Stretz
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-28 13:24 UTC by Dallas Engelken
Modified: 2004-05-28 07:22 UTC (History)
1 user (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Dallas Engelken 2004-05-28 13:24:49 UTC
i just installed a new build today, i was running 19XXX before and didnt have a 
problem...  its exiting 139, which may or may not mean anything to anyone.

[root@dev spamc]# spamassassin -V
SpamAssassin version 3.0.0-r20200
  running on Perl version 5.6.1

[root@dev spamc]# echo | spamc -u root
Segmentation fault

[root@dev spamc]# STATUS=$?
[root@dev spamc]# echo $STATUS
139
Comment 1 Justin Mason 2004-05-28 13:42:10 UTC
moving to 3.0.0 queue.  this needs to be fixed ASAP...
Comment 2 Sidney Markowitz 2004-05-28 14:30:30 UTC
This tWO line patch makes the segfault go away. I don't have time right now to
look at it carefully enough to say that it is the right fix, but if somebody
else has a chance this should point directly to the problem and may be all that
is needed. I'm pasting it in here instead of attaching because it is so small:

--- spamc.c     (revision 20551)
+++ spamc.c     (working copy)
@@ -479,6 +479,8 @@
        ret = get_current_user(&username);
        if ( ret != EX_OK )
            goto finish;
+   } else {
+     username = strdup(username);
    }

    if ((flags & SPAMC_RANDOMIZE_HOSTS) != 0) {
Comment 3 Malte S. Stretz 2004-05-28 14:38:52 UTC
Takin' as this is my fault. 
Comment 4 Malte S. Stretz 2004-05-28 14:48:24 UTC
Done, r20552 has a similar fix. 
Comment 5 Sidney Markowitz 2004-05-28 15:13:04 UTC
Are you sure it is fixed correctly? It looks to me as if get_current_user
unconditionally overwrites the -u parameter with the statement

 *username = strdup(curr_user->pw_name);

I didn't try to run it... Am I missing something?
Comment 6 Malte S. Stretz 2004-05-28 15:22:04 UTC
You're right. I guess I hit the wrong key combination in vi. r20554 is better.