Two vB_Datastore_Filecache issues

[dlfman]

For starters, I'd like to say you guys keep impressing me with how smooth these upgrades are. I came all the way from 3.0.5, and the -- very lengthy -- upgrade procedure went without any hicups. :)

A few small issues, though.

- I am not too fond of the fact that the path for "vB_Datastore_Filecache" is hard-coded. Perhaps a future version will allow a path to be set in config_inc.php?

- But I'm really not happy with this suggestion in the FAQ, at:

http://forum.vbulletinsetup.com/f7/vbulletin-optimisation-tips-2.html

Especially the part where it reads:

"Make sure that you have /includes/datastore/datastore_cache.php set to 777 so that it may write to the file."

LOL. Since when is making files world readable/writeable good advice? Perhaps you should reword it to something like:

"Make sure /includes/datastore/datastore_cache.php is owned by the same user the web server runs as, and that ONLY this user has read/write access on that file (typically, chmod 600)."

datastore_cache.php potentially contains structures with passwords, too!

Otherwise, yet another brilliant release. :)

[Wayne Luke]

That site isn't an official vBulletin site. However, I would simply recommend that you place .htaccess protection on the datastore directory with a <deny from all> directive and make it so it is not accessible from the world wide web. In fact, you can place a deny from all on the entire includes directory if you wanted to.

[Zachery]

The datastore should not contain any overly sensitive information in it.

[dlfman]

That site isn't an official vBulletin site. However, I would simply recommend that you place .htaccess protection on the datastore directory with a <deny from all> directive and make it so it is not accessible from the world wide web. In fact, you can place a deny from all on the entire includes directory if you wanted to.

You're right: I did'n't even notice that that wasn't the official site. :) My bad.

As for permissions, I don't want other users on my system roaming around in it, either; or, with the write access they have, try and manipulate the datastore. So I did what I said: changed the permissions so only the "nobody" user has access to it.