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.
