What are the possible exploits if settings.php is writable? I have recently had to set up Drupal on shared hosting using suPHP. This is a first for me, an install where all the files are writable by the user by default. All the Drupal documentation and the Drupal built in status report will warn you of the folly of having your settings.php writable by the web server process.

Option 1:
I can log into the shell and secure the settings.php by making it read-only to my own account (and the webserver account which is running as me).

Option 2:
I can log into the shell and make all the files and folders read only to my own account (and the webserver account which is running as me) which may have to be changed every time I want to install a module etc. This will be kind of a pain to maintain.

My question is: Is there a significant difference in the security risk between the two options? What are the specific exploits that are possible due to having the settings file writable by the webserver process vs. the other core files?
Option 2 is marginally better, but if you get p0wned, a hack script will chmod the file before it tries to append to it, which pretty much renders permission-based protection useless.

Personally, I would make up shell scripts to take care of the permissions for you.
For deployment, something like

find docroot/ private/ -type d -exec chmod 555 {} \;
find docroot/ private/ -type f -exec chmod 444 {} \;
find sites/default/files/ -type d -exec chmod 755 {} \;
find sites/default/files/ -type f -exec chmod 644 {} \;


Then, when you want to run drush or make updates

find docroot/ private/ -type d -exec chmod 755 {} \;
find docroot/ private/ -type f -exec chmod 644 {} \;


You should also read through Securing file permissions and ownership.  This article includes a different version of shell script for fixing permissions, and uses a slightly more restrictive scheme.