[cd34]

The issue, and I've submitted numerous bugfixes, is that along the way, wp-content gets marked 777, and later plugins/themes write files, wordpress forgets that it should use the FTP layer, and later on everything is pretty much screwed up.

There are two ways to run the machines, setuid (which most companies do) where the apache process runs as the same username as your FTP account. The problem here, is, when wordpress (or any script is compromised), you've given those processes the ability to write over your entire website - every file that you have is able to be overwritten. The alternate way is to run apache in a low-privilege environment - in which case if wordpress is compromised, it is unable to overwrite most of the files.

Somewhere along the line, wp-content was chmod 777 on a system running in low-privilege mode, and some files got upgraded or written to as www-data, then, wp-content was changed back at which point FTP cannot overwrite the files owned by the webserver.

The simple solution, which wordpress has avoided for the last 2-3 years, is a patch that determines what mode it is running on, and, when running in a low privilege environment, uses umask to properly set permissions so that the FTP user can overwrite them.

I've been working on an alternate solution to fix this so that it isn't an issue, but, wordpress assumes that all hosts are running setuid, and doesn't see it as a problem.