[Bug 4370] Failed exec in forked helper process continues its miserable life

[bu...@bugzilla.spamassassin.org]

http://bugzilla.spamassassin.org/show_bug.cgi?id=4370


Mark.Martinec@ijs.si changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Additional Comments From Mark.Martinec@ijs.si  2005-08-05 07:20 -------
Justin, thanks for fixing the original problem. I'm reopening this bug 
because I discovered another code path which can still (today's CVS) 
produce the originally reported problem (runaway cloned process). 
Because the problem is in the same routine and is actually the same 
as the originally posted, I decided to re-open this old bug 
instead of creating a new report. 
 
Namely, apart from exec failing in Util::helper_app_pipe_open_unix, 
there are other failure modes possible in the forked process. 
In my new case it was a failure to open a temporary file 
(it happened because I had misconfigured directory protections). 
 
Here is a debug output, note the reported PID and the continuing 
of the process 90619: 
 
[90359] dbg: info: entering helper-app run mode 
[90359] dbg: dcc: opening pipe: /usr/local/bin/dccproc 
  -H -R < /var/amavis/tmp/.spamassassin90359CP4p6otmp 
[90619] dbg: util: setuid: ruid=110 euid=110 
[90619] dbg: info: leaving helper-app run mode dcc: check failed: 
  util: cannot open /var/amavis/tmp/.spamassassin90359CP4p6otmp: 
  Permission denied 
  at /usr/local/lib/perl5/site_perl/5.8.7/ 
     Mail/SpamAssassin/Util.pm line 1246. 
[90619] dbg: uridnsbl: select found 1 socks ready 
 
So the following open failed: 
  # acceptable to die() here, calling code catches it 
  open STDIN, "<$stdinfile" or die "util: cannot open $stdinfile: $!"; 
 
and instead of the cloned process going away, the die was caught by 
some eval and the cloned process continued its life pretending to be 
a genuine main SA process. 
 
In summary: any possible 'die' in that forked child process must be 
captured within that same routine, and must lead to the same POSIX::_exit(1) 
call at the end of that routine. 
 
As a sidenote, I should say that this time my life was saved (ok, the 
troubleshooting time reduced) by a safety net that is now built into 
amavisd-new around its call to SA. You might be interested in providing 
a similar safety net in spamd, just in case: 
 
(simplified, but essentially the:) 
 
  my($saved_pid) = $$; 
  $mail_obj = $spamassassin_obj->parse(\@lines); 
  $per_msg_status = $spamassassin_obj->check($mail_obj); 
  if ($$ != $saved_pid) { 
    eval { do_log(-2,"PANIC, SA produced a clone process ". 
                     "of [$saved_pid], TERMINATING CLONE [$$]") }; 
    POSIX::_exit(1);  # avoid END and destructor processing 
  } 
 
Mark 



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.