3 ms·
You can upgrade WordPress automatically now without using FTP. It means that PHP has to execute with write permissions to the files involved however. Exacerbati
by 9oliYQjP 17y ago
You can upgrade WordPress automatically now without using FTP. It means that PHP has to execute with write permissions to the files involved however. Exacerbating this security risk, a lot of people run mod_php which means PHP executes as the apache user, thus giving write permissions to every other website on that server. They'll either chmod 777 or chown www-data (or apache) the wordpress folder/files.
I personally use FastCGI+SUExec to ensure that WordPress' PHP code executes under a specific user account other than Apache's. It does not address the possibility of WordPress code itself somehow being hacked, but it does provide some sort of sandbox protection to the site.
I'm not thrilled with WordPress' past security track record, but I think they have made it so easy to use that a lot of users simply throw the scripts up on a shared server without knowing exactly what they're doing so far as server configuration goes. I wonder how many WordPress blogs are exploited because of a stupid permission setup?
- jonknee 17y agoHow does it work without FTP? Last time I tried to upgrade it asked for the FTP u/p.
- bugs 17y agoThe same way installing plugins without ftp and writing config files; the files that need to be upgraded just need to be writable by the server.
- 9oliYQjP 17y agoIf it's asking for FTP details, the problem is that Apache does not have write permissions to the files. The UX is pretty bad in that it doesn't let you know that it doesn't have write permissions, it just ignores that fact and presents the FTP details. Here's where a lot of the security problems arise. As I mentioned, a lot of people are on a shared host and using mod_php. The only way they can make their files writable is to somehow give Apache write access to them. That opens up the possibility for other sites on the shared server to execute PHP that also writes to these files. If you're stuck in this position, I'd recommend as a hack/workaround, to temporarily chown the files to www-data/apache. Perform the upgrade, then change ownership of the files back. Ideally, if you're setting up your own server, I'd recommend FastCGI/SUExec: http://www.howtoforge.com/how-to-set-up-apache2-with-mod_fcgid-and-php5-on-debian-lenny http://www.howtoforge.com/how-to-set-up-apache2-with-mod_fcg... You have much finer-grained control over how your PHP can execute. Alternatively, although I have no experience with it, you could try suphp to achieve a similar effect but by sticking with mod_php.