On Wednesday 08:45 AM 8/20/2008, Jim Davidson wrote:
Overall, it seems one thing to do would be to switch to filename-based
cache keys by default, leaving the dev/inode pair as an option for
folks who run sites with large symlinks and want to benefit from
caching objects just once.  I think that should avoid the data
corruption cases John pointed out with minimal downside.

Actually that wouldn't have fixed the problem in the code that led us to find out about this in the first place. The change that I suggested does fix that problem, though, and it directly addresses the limitation of mtime's one-second granularity--which is the crux of the issue. The patch below (really just a one-line change) implements this fix:

------- 8< --------------------------------------------------------------------- --- aolserver-4.5.0-orig/nsd/fastpath.c 2006-04-19 10:48:47.000000000 -0700 +++ aolserver-4.5.0/nsd/fastpath.c 2008-08-19 21:22:26.000000000 -0700
@@ -507,9 +507,11 @@

     if (servPtr->fastpath.cache == NULL
-           || stPtr->st_size > servPtr->fastpath.cachemaxentry) {
+           || stPtr->st_size > servPtr->fastpath.cachemaxentry
+           || (time(NULL) - stPtr->st_mtime) < 2) {
-        * Caching is disabled or the entry is too large for the cache
+        * Caching is disabled, the entry is too large for the cache,
+        * or the file was modified too recently to be cached safely,
         * so just open, mmap, and send the content directly.

------- 8< ---------------------------------------------------------------------

We've tested this fix extensively against the code that was hitting the bug before, and I can verify that it resolves the problem there. As far as I can tell this fix would resolve the issue in any standard scenario (and certainly all of the ones I've outlined thus far).

Given that this is a straightforward, user-transparent change that would have only a negligible impact on fastpath caching, and considering the security implications, I'd suggest that this change be applied to the AOLserver code in CVS.

BTW, Jeff, the scenario you'd outlined that you thought would trip this up...:

   13:50:21 - create file
   13:50:21 - serve file (gets cached)
   13:50:21 - delete file
   13:50:21 - create file again (reuses inode)
   ... time passes ...
   13:55:11 - serve file

...actually wouldn't, because the file would NOT be cached in the second line. The whole point of this strategy is that a file won't be cached if it's been modified within the threshold time (2 seconds in the patch above).

- 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.

Reply via email to