Ehud Tenenbaum <analyzerat_private> 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 <bugat_private>. 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
This archive was generated by hypermail 2b30 : Mon Feb 25 2002 - 16:25:55 PST