Consider this use case: - You use git or another version control system to store for a bunch of static html files you serve with Aolserver. - You check out all of your static html files. Because they're all checked out at the same time, many of them have identical timestamps.
Could the user get the wrong version of an html file they're being served? What about this scenario: - You have a web application that allows administrators on various sites hosted on your application to download a list of user names and passwords (this is a slightly contrived example). They can download it to CSV. - Admin #1 generates this file. You create a unique filename for their site_id, because you want a unique filename to return back to the user: site-1234-passwords.csv. You return this file to the admin. - Admin #2 generates their file. You create a unique filename for their site_id, because you want a unique filename to return back to the user: site-5000-passwords.csv. You attempt to return this file to the admin. Because their request was in the same second, however, they get site-1234-passwords.csv? Do I understand the problem correctly? I think both of these scenarios are pretty common examples of the way people use Aolserver currently, but I'm not sure if I'm understanding correctly the bug. Jade Jade Rubick Director of Development Truist 120 Wall Street, 4th Floor New York, NY USA [EMAIL PROTECTED] +1 503 285 4963 +1 707 671 1333 fax The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Mon, Aug 18, 2008 at 4:20 PM, John Caruso <[EMAIL PROTECTED]>wrote: > 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. > -- 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.
