> >I have tried this and it makes no difference -- it looks like non > >blocking mode is simply not being set. > > And this verification code doesn't fail? > > # test that we really *are* in the blocking mode > !$socket->opt_get(APR::SO_NONBLOCK) > or die "failed to set blocking mode";
That's correct. Deep inside Apache, it is keeping track of the blocking modes as if they've been set but .. what it returns apparently does not reflect reality. I'm tracing through the Apache code to see what's actually happening. > I think it's this change that introduced this "feature": > > *) SECURITY: CAN-2004-0493 (cve.mitre.org) > Close a denial of service vulnerability identified by Georgi > Guninski which could lead to memory exhaustion with certain > input data. [Jeff Trawick] > > So you don't need to check all the differences. I think apr was affected > as well. Great. I'll look at the patch. There are no relevant diffs between 0.49 and 0.50 in the apr/network_io/unix/sockopt.c so the damage must have occurred somewhere else. > In fact APR is broken as it ignores the APR::BLOCK_READ flag in filters. > But nobody at httpd-dev/apr-dev seems to even care :( So filter writers > need to manually set the socket to the blocking mode, which sucks :( I agree. Of course, the deepest irony here is that what we actually should be doing for our application is writing APR::Poll support into mod_perl because Net::Server::Mail expects a non-blocking handle.. Thanks for the help. TTUL Ken -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
