On Monday 03:38 PM 8/18/2008, Jeff Rogers wrote:
While I'd agree this is a bug in fastpath, the real problem is that fastpath is being used at all in this case. The intent of fastpath is to avoid reading a seldom-changed file from disk.

I'd agree that that's the intent, but the caching is hidden within ns_returnfile and it's not clear at all from the user's perspective that this alligator is lurking in the swamp. Using ns_returnfile in this way may not be the best approach in any particular situation, but it's nonetheless a completely valid usage and isn't contraindicated in any AOLserver docs I've seen.

It's not difficult to come up with examples where it might happen, BTW...say, a web service that returns the result of an operating system command to a user.

I think Jade makes a good point that this is not only a bug but potentially a security issue.

It happens to be used in ns_returnfile since that is the normal use case. On unix the fastpath cache is keyed off the dev/inode probably to keep the hash key shorter. Windows doesn't have device and inode numbers so it uses the filename as the hashkey, so it wouldn't run into this problem.

No, it can still easily run into this problem--it's just that the file name needs to be the same in both cases (which actually did apply in my client's case, and caused confusion in the early debugging of the problem, since the assumption was that using the same file name and/or path name was the source of the problem).

From the server side, this could be fixed by:
- adding in the filename to the hash key or checking that it is the same

No go, as observed above.

- making ns_unlink flush the entry from the fastpath cache

Nope, since the file can be removed via (e.g.) exec rm.

- restricting what fastpath will cache - e.g., don't cache anything in /var/tmp or /tmp or a configuration-specified directory.
- adding a "-nocache" flag to ns_returnfile

This last is the one I'd considered as well, but the problem is that it puts the onus on the user to know that they should use the flag, and that's unlikely to be clear to them.

I don't think your suggestion of waiting for cache entries to age a second or two would work well, it just moves the race condition around and adds a whole lot of disk activity when a busy server is warming up - static files might be read a few dozen times instead of once.

Nope, not at all. The only files that would get read more than once would be those that were served within one second of being generated--which wouldn't apply to any content that fits the definition of "static".

So this is actually a fairly non-intrusive fix. The main limitation is that it relies on the file timestamps and the server timestamps being synchronized, which may not always be true. But I can't think of a better solution. Simply put, fastpath caching is inherently broken because it's not possible to guarantee that the file in question really should be served from cache (again, short of a cache-defeating checksum).

Fixing it from the application side is much easier. Just use ns_returnfp instead of ns_returnfile, on the open handle if you generated the file from tcl code and it's convenient to get the handle, otherwise by opening the file right there:

Yep, and that's more or less the workaround I'd suggested to my client. But my point here wasn't to ask about potential workarounds but to highlight the issue itself, since I haven't seen it mentioned before.

- 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