Fool me twice, shame on… insecurity.
Far too often, Step 1 in deploying a file-manipulating script on Apache is setting wide-open (777) permissions on working directories. This seems wrong on a few levels, but is often unavoidable. The security risks of this are often overstated, since most real hosts chroot Apache, or use suEXEC or something like it. So, hey, chmod -R 777 , why not? The world may be able to write to my folders but they’ll never get there.
Well, one reason is the ghosts of hacks past have many web hosts configured (mod_php, mod_perl, whatever) to refuse to run scripts that have 777 permissions. The result is usually an internal server error (500 exception) and, of course, no output from the script itself, since it never even got to run.
I had encountered this before when deploying and customizing a large CiviCRM system, and with some Q&D PHP scripts of my own. But it was certainly not the first thing on my mind last night.
My wife wanted a new site to display and possibly sell some of her photography. Her needs matched WordPress’ capabilities well, so I went that route – a WordPress install with a nice FotoFolio template. But when it came time to generate image thumbnails – nada – just blank and black boxes. By viewing the HTML source in the browser, I could see that the img tag src’s were calling timthumb.php. Pasting this into a new browser address bar revealed the source of the problem – the internal server (500) errors.
I rechecked the FotoFolio setup instructions (including the overzealous chmod’s for TimThumb’s sake), and verified the script source. 777, 755, whatever it takes. This process was made a bit more challenging since I had again lost ssh access to the host, and had to resort to using cpanel’s File Manager. In frustration, I finally went back to square one and found that it wasn’t the temporary cache directory, parent directory, or template directory that had the offensive 777 permissions, but one at a higher-level. Apache was refusing to run the script if any parent folder (between itself and document root) had world execute or write permissions. I can understand the thinking, but wow. 755’ing that puppy fixed the problem and I was off and running at 1:00 am.
While searching for a solution, I saw that others had stumbled into this and found a few FotoFolio-based sites with black box images – telltale signs of the same struggles. So, I would offer the following suggestions to others who might hit this:
- Set the 777 permissions as directed by the instructions, but be prepared to back off if needed. The FotoFolio instructions included setting 777 on the scripts directory, not just the cache directory. Doing this doesn’t work and isn’t necessary.
- If you see incorrect thumbnails and preview images, view the source in your browser, find the img src bit with the timthumb.php call, and paste it into a browser. This will reveal if it’s failing.
- If you have upload or resize problems with large images, check the error_log file. If you see memory allocation errors (“allowed memory size exhausted”), you may have to modify the ini_set call in timthumb.php to be under your memory limit. A phpinfo script will show you your memory limit. Of course, uploading only reasonably-sized images helps, too.
The site is basically up, so check it out: reflectionsofHismercies.com. FotoFolio is a nice theme and, if things continue to go well, I’ll stick with it, although I will need to customize it for a shopping cart, etc.
Perhaps the moral of this story is that insecurity can be costly. Too often, fear (insecurity) of an exploit can lead to ineffective (insecure) security measures. In this environment, the 777 restrictions added costs but no benefits. Hosts and developers should take precise, effective security measures, rather than using a shotgun approach.
