Is a writable file security hole?

If the name of the file isn't dependant on user input, then there is little risk. If it is, you have to make real sure that the user dependant part is well sanitized, by removing all potentially dangerous characters, such as ., / or .

Others have mentioned a possible DOS by filling up the disk; but you get that risk with a database, too.

There is then another risk, which is not a vulnerability in itself but could serve as one. The attacker could use that method to create content of his choosing on the server and use it to exploit a vulnerability by getting it executed. Most commonly, the problem present itself if you let the user create a .php file and let it be accessed through the server. The user just needs to open http://yourserver/uploads/hisupload.php to do what ever he wants.

The safest way to avoid this problem is to put all uploaded files outside the server directory. That means you must then serve the files through a php script of your own, not directly to the outside. Usually on Unix you have your php scripts unders /var/www/html. Just have you script write them under /var/www/uploads, for example, and there is no way for the web server to go there, unless you've done something stupid with your httpd.conf.

If you can't control this, then use a .htaccess to limit access to that particular directory, and/or make sure that the files cannot be executed as PHP or server-side includes (.shtml) by always appending a safe extension such as .html or .txt.

In addition the the DoS risk, you have to make sure that the content is sanitized so that when PHP reads it back out of the file, data doesn't get interpreted as code. One advantage of using SQL is that sanitizing SQL data is a fairly standard and well-understood process, whereas I'm not sure wha tthe state of the art is for PHP.

Beware of the potential for DoS from the respect of the script being able to fill the file system it has write access to.