Re: bug in procmail (ver 3.14 maybe others?)

From: Philip Guenther (guenther@sendmail.com)
Date: 02/24/02


To: Ehud Tenenbaum <analyzer@2xss.com>
Date: Sun, 24 Feb 2002 11:18:18 -0800
From: Philip Guenther <guenther@sendmail.com>

Ehud Tenenbaum <analyzer@2xss.com> writes:
>Philip Guenther wrote:
...
>> (As a (long) side note: the only way I know to send a SIGALRM to a
>> setuid process is to exec it directly, leaving an alarm pending past the
>> exec, and even then new enough OSes don't even allow that. It worked
>> under gdb because tracing disables setuid execution, but otherwise I
>> don't know how you would do it. You can send 'tty signals' (INT, QUIT,
>> TSTP, HUP, WINCH, INFO) to setuid processes if it's in one of your
>> sessions. That extends to some other signals (KILL and STOP), at least
>> some of the time, but I don't see how to arbitrarly send other signals
>> to setuid processes.)
>
>On the other hand I disagree with you on this one, sigalrm is occur when
>using alarm() in a program and therefor can be reproduced even without
>the tracing (that how BOS found it in the first place) this has nothing
>to do with gdb.

When a setuid process gets SIGALRM because it called alarm(), that isn't
'arbitrary'. That's expected and (presumably) planned for: if a program
crashes from its own alarm() call, then it's simply a bug. Perhaps it
would have been clearer if I had said that I don't see how to send an
arbitrary and _unexpected_ signal to a setuid process. When I try to do
so under OpenBSD, I get EPERM errors.

<pause>

Ick, I see that this is an area where OpenBSD is more paranoid than
others, as both FreeBSD 4.2 and Linux 2.2.17 allow you to send more than
just tty signals to setuid processes in your session. Seems like a bug
to me, but one we'll have to live with a goodly while. Ah well, yet
another thing to audit in user programs.

As for procmail crashing from the SIGALRM it sent itself with alarm(),
you should upgrade to 3.15.2 and see if the problem is gone: versions
before then definitely could be made to do unsafe things in signals
handlers. I'll fix for the next version the "lastexec==NULL in
ftimeout()" problem you pointed out so that procmail won't crash when
sent unexpected SIGALRM; if you find other problems in 3.15.2, please
email them to <bug@procmail.org>. Ditto for 3.22, though you should
probably wait til 3.23, to be released Real Soon Now, before spending
time banging on it.

Philip Guenther
Procmail Maintainer



Relevant Pages

  • Re: disable beep for wall command
    ... sigactionwith the first parameter being SIGALRM, ... Sorry but actually SIGALRM relates to the program event signals and ... but it isn't related to any type of alarm sound. ... name will be different in each sound system and in the old OSS days I ...
    (Debian-User)
  • Re: timeout on connect
    ... server usingf connect. ... interrupting connectwith SIGALRM. ... alarm(), ualarmor setitimer, then issue a blocking ... If you catch no other signals, ...
    (comp.unix.programmer)