I am all for security in depth, but the www-data processes still has the private key in memory. Makes it slightly harder to get at, through other vectors though.
You are really protecting against local, non-root access to your box, especially when that user is the nginx child process. This can manifest itself in a number of ways, but most roads lead back to improper input sanitization and/or using user input in shell command execution.
Using the Unix file permissions to our advantage and the properties of fork'd child processes, you can scope your risk to a highly skilled adversary rather than the common adversary.
Note that not only is your SSL certificate at risk, but every file the web-server needs to read including configuration files containing passwords, API keys, and crypto keys.
Yes, great post. I just went through this same discovery myself. Was worried the worker processes would need access, but thankfully they do not.
For a site that's (apparently) hosting an article about a security vulnerability, they _really_ need to turn debug mode off.
For those wondering what I'm on about when the site starts functioning again, I got an error page akin to a Django page with `DEBUG = True`, listing useful information as the full path to the PHP script being run, the user it's being run as, , etc.