Why Shared Hosting Is (Usually) Not Secure, And How To Address That Problem
If the "shared hosting" service you are using allows you to see the files of other customers when permissions are not carefully set, you MUST NOT run the stock, out-of-the-box Symfony distribution in that environment. This is because Symfony's cache manager creates world-writable PHP scripts in the cache folder. ANY CUSTOMER of the web host could overwrite those with scripts of their own and take over your site completely. It's not "if you get hacked." It's more like "when you get hacked."
Symfony's cache manager does this regardless of the permissions you have set on your project as a whole. Setting umask will not help. There is explicit code in the cache manager to override umask and make sure everything in the cache is writable by everybody. With hundreds of clients on a single box this is, of course, not safe.
To be fair, Symfony does this because on many hosts PHP scripts run as "nobody." On such hosts there is no other way to make the cache folder work. On a server that serves only your own site or sites this is acceptable. But on a shared server with other hosting customers, this workaround is worse than not working at all because it is a security failure waiting only for the arrival of one untrustworthy user, or one otherwise-compromised site, on a boxful of sites that aren't yours.
Some hosts, notably Pair, allow your scripts to run as your own account rather than as nobody. This is called suPHP. Often it is not turned on by default, you must enable it or ask for it to be enabled. See Pair's knowledge base article on suPHP.
Unfortunately, Symfony is not set up to take advantage of it well, because of the code in the cache manager that bludgeons the permissions in the cache folder right back to world-writable status and cannot be turned off.
I filed a bug on this in September '08 and also provided a patched version of sfFileCache which is attached to that ticket:
To use my version of sfFileCache to address this problem you must add the following code to your site's main config.php file:
umask(0077); $sf_symfony_file_cache_options = array( 'leave_umask_alone' => true, 'dir_permissions' => 0700, 'file_permissions' => 0600);
If you must deploy Symfony in a shared hosting environment - containing other sites not built by your own company - then you must verify that at least one of the following is true:
1. GOOD: the host is using "chroot jails" for each site so that users cannot see each other's files. When you log in and type "ls /home" you don't see teeming hordes of other accounts. (Adjust /home based on what the home directory of your own account is. Also try "cd ..; ls" at the ssh command line to see whether you can see other accounts.) This can be thought of as poor-man's virtual machine hosting; you can still see other people in the process table but you can't see their files which is by far the bigger risk. If you have cheap shared hosting you probably don't have this feature, but check and see, you might be in luck.
2. OKAY-ISH: (a) the host is providing suPHP so that scripts run AS YOU, not as "nobody," and (b) you have replaced the stock sfFileCache.class.php with my version and added the correct settings to config.php as described above. This solution works but still requires that you be vigilant and watch out for other code that might not be managing permissions well, such as the FCK file upload manager. So it's not as good as a chroot jail. Of course, there is no warranty for my version of sfFileCache - it solved a problem for me once, but your results may vary.
3. NEVER OKAY: the host runs PHP scripts only as "nobody", with no suPHP option, and you can see the directories of other clients of your web host. Since Symfony requires writable cache folders in order to work (which is not necessarily a bad thing, by the way), no amount of patching will make this situation work. Get better hosting.
In general, if you have a choice, don't use shared hosting at all. Get "virtual server" hosting (virtual machine-based hosting; usually based on VMware or XEN) if your budget does not allow for dedicated hosting. In these setups you have your own virtual operating system and no one else can see your files. Others impact your performance but not your security (short of a major bug in the virtualization itself, which would not be directly Symfony-related and would likely be patched quickly by a competent host).
File permissions go away as an issue with virtual server hosting, at least with regard to the security impact of other sites. And virtual server hosting is only a little bit more expensive than shared hosting. So I suggest that you simply use it.
NOTE ON SYMFONY 1.2: a brief examination of the 1.2 cache manager code indicates this problem is still very much around. I have not yet attempted to use my modified sfFileCache code with Symfony 1.2.
Kahn_AU: that's true and I do use them. We also use http://servergrove.com/ which offers extremely reasonable pricing on VPS setups which are already configured for Symfony. Notably including ready to rock APC cache which is a big win. They also offer shared hosting, I've discussed the issues with them and while I respect their position I can't recommend it, due to the fact that it's still possible to find and tamper with another customer's Symfony cache folder and run code of your own. So just use their $20/mo VPS instead and don't ever worry about this again. -boutell
boutell: Since it is a direct reference to us, I need to comment on this. Our shared hosting platform runs each domain under its own unix user, isolating customer files. Additionally, each domain gets its own temporary directory where session data is stored. No files are shared among customers. Customers cannot see each others files. Having said this, if your budget allows it, we still recommend VPS hosting for symfony apps. The benefits are endless. - servergrove