Hello John, I just think that you're introducing complexity to a common and widely used infraestructure (with a hack), just to hide the flaws on your side.
I don't like this hack. It's not the correct thing to do, not even if you make some parameters (like the "timeout") changeable via the configuration file. It just doesn't feel good to me. But, of course, you are free to patch your own AOLServer. I can't (and won't) complain about it. Someone said that this was not an academic discussion... but I am afraid that to some extent it is. We've been speaking that the cache can't know if its contents are good or not, if the changes happen out if its scope, and it's never notified of it. But, since Linux version 2.6.13, inotify is into the kernel, and aolserver can subscribe to a path, so know if that file has been deleted, modified, or anything else. That's the way a cache can know if the file has been altered in any way, and it should be marked as dirty. As easy as that... but I know it is harder than that one-line-patch. Now you can do whatever you want... as long as you don't ask me to patch my code with the dirty hack you proposed. I don't like having AOLServer's SVN version patched with this. Best Regards, Juan José - Juan José del Río | (+34) 616 512 340 | [EMAIL PROTECTED] Simple Option S.L. Tel: (+34) 951 930 122 Fax: (+34) 951 930 122 http://www.simpleoption.com On Wed, 2008-08-20 at 13:21 -0700, John Caruso wrote: > On Wednesday 12:30 PM 8/20/2008, Jeff Rogers wrote: > >I can very easily come up with a scenario that breaks your patched > >fastpath just as easily as the original, to which you can rightly say, > >"but why would you do it that way?". And you would be right. > > Do it, then. This is the simplest example I've given that exhibits this > bug: > > eval exec /some/external/program --output-file $tempfile > ns_returnfile 200 text/plain $tempfile > ns_unlink $tempfile > > This is ALL that's required. No external meddling, no munging of file > modification times, nothing else. Three lines of Tcl code. By all means, > show me an example that defeats this patch that's anywhere near as simple > as that. > > And far, far more to the point: that's as NATURAL as that. I'd assert > that that example code is perfectly intuitive--and right up to the point > where I pointed out this bug in the first place, it would have been > accepted without remark on this mailing list. *Now*, of course, serving > anything but 5-year old files with ns_returnfile is proof that one should > give up computers for a living, and not recognizing the holy contract we > enter into with AOLserver when we invoke ns_returnfile that our files must > continue to exist for at least one more second is a valid reason to > contemplate suicide to end our worthless existence. > > Look: we discovered a serious bug in AOLserver's fastpath caching > mechanism that can cause both data corruption and information > leakage. I've explained that bug carefully, in the face of confusion, > obfuscation, and a continual stream of utterly unnecessary abuse. I've > offered a tested patch that provides a minimal, correct-by-inspection, > user-transparent, massive improvement over the current behavior, despite > my near certainty (based on previous experience) that it'd just lead to > another round of carping, finger-pointing, and refusal to accept that > there's even a problem here in the first place. I've explained why the > patch makes sense (and in fact addresses exactly the limitation that > should have been considered when the fastpath caching mechanism was > initially designed). I've responded to all serious concerns, respectfully > and without returning any of the bile that's been sent my way. > > For anyone who's serious about securing your installation, you have the > patch now, and I'd strongly suggest that you apply it to your AOLserver > sources. I'll still respond to serious concerns that don't just rehash > the same excuses, but otherwise I'm done. > > - John > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL > PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: > field of your email blank. > > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
