Re: Data "corruption" with fastpath caching

On Monday 04:56 PM 8/18/2008, Jade Rubick wrote:
>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?

Nope, because in this case the inodes for the files would be different, so 
fastpath caching would distinguish them.

>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?
Yep, it could happen in this case, assuming the files are deleted after 
they're returned to the user via ns_returnfile.

As I mentioned, this bug wasn't discovered through code review or any 
theoretical process--it was causing problems in live code, and it was 
extremely difficult to track down.  And the damage assessment is still 
underway.

- John