who should own the web root of my server?

I read a book about security in web servers and I found this:

> If your web server has the ability to write to the files in your WordPress directories, then the automatic upgrade functionality works. If not,WordPress prompts for your FTP credentials to update the files for you. Both of these situations concern us. In general, your web user should not have write permissions to your entire web root. This is just asking for trouble, especially on a shared hosting platform; realizing, of course, that certain directories such as the uploads folder must be writable by the web user in order to function.

Professional Wordpress by Hal Stern

What I want to ask is who is the web user of my server? I'm using Nginx and PHP5-FPM. The web root folder of my server is owned by raymond:raymond. Nginx is running as nginx:nginx and PHP5-FPM's listen.owner is set to raymond and listen.group is also set to raymond

The web root directory permissions is drwxr-x-r-x, my public_html is also set like that.

So how can I know if I'm in trouble with this setup?

4 Replies

@rymngh:

This is just asking for trouble, especially on a shared hosting platform
Linode is not your average "shared hosting" platform!

On shared hosting, the primary concern is to protect each site from a potential rogue site on the same server. Shared hosting customers can and do try to break into one another's accounts. But shared hosting companies usually don't care whether or not a site can harm itself. A typical cPanel setup leaves pretty much everything in your document root writable.

On a VPS that you control, rogue customers are less of a concern. You should still try to protect sites from one another if you have more than one site, but your primary concern is to minimize damages if anything bad happens to your own site. This means protecting the server from any hacked site, and protecting a site from any rogue script located within itself (which may have been uploaded by a remote attacker).

Your current setup (nginx running as its own user and FPM running as the website owner) is the way I'd set it up if I wanted WordPress to be able to update itself. If there were additional websites, each would be owned by its own user, and each would have its own FPM pool. This is similar to how shared hosting works, and it works pretty well.

However, there are a couple of potential issues with this setup, if you want to make your server really secure.

1) Does the "raymond" user have the right to run commands as root? (Is it in the sudoers file?) If so, this is a bad idea. Websites should not be owned by privileged users. Create a separate user for administrative tasks. Also, lock down open_basedir so that PHP scripts can't access anything except its own user's home directory, /tmp, and /dev/urandom. (Protect your server from your own site.)

2) I said that your setup is what I'd do if I wanted WordPress to be able to update itself. But do you really need WordPress to be able to update itself? WordPress and its plugins have a history of nasty security bugs. If (or rather, when) one of your files gets hacked, everything that is writable by that script will be vulnerable. So it might be a good idea to minimize the amount of writable stuff. (Protect your website files from rogue scripts within itself.)

You can use SVN to update WordPress from the command line. This doesn't update plugins, but if you leave the wp-content directory writable, you will still be able to update plugins from within WordPress, and hacked plugins won't be able to contaminate WordPress itself. If you want to get extra fancy, it's even possible up update plugins from the command line by using scripts like this.

Doing this properly requires a rather complicated scheme of users and permissions. Each site would be owned by one user (e.g. raymond) that you normally use for SSH and SFTP, and the FPM pool for the site would be owned by another user (e.g. raymond-fpm), belonging in the same group. Anything you want to make writable would have to be made group-writable by "chmod g+w"ing them.

Hello hybinet

Actually my server only hosts 1 website. I am the only user of my server and I don't foresee that I will add another one. raymond doesn't have sudo rights, it's just a user that owns the web root directory.

Yes, i really want the automatic updates since it is so convenient. I thought that updating Wordpress is the best way to stay secure? How can updating Wordpress in the admin panel make my server less secure?

Thank you for the open_basedir tip. And thank you for being so helpful!

@rymngh:

Yes, i really want the automatic updates since it is so convenient. I thought that updating Wordpress is the best way to stay secure? How can updating Wordpress in the admin panel make my server less secure?
It's not the update process itself that is insecure. The problem is the ownership structure that allows that to happen.

In order to update itself, WordPress needs to be able to overwrite itself. There's nothing wrong with that if your files are only ever overwritten by official WordPress material. But the ownership and permissions structure that allows WordPress to overwrite itself will also allow any PHP script located inside your document root to overwrite WordPress. This means that it may be possible for remote attackers to inject spam and viruses into your theme if they gain control of an insecure plugin. The only way to prevent this is to adjust ownership and permissions so that nothing, not even WordPress itself, can overwrite WordPress.

If you're sure that you're only using well-written, well-tested plugins, by all means keep your current ownership structure. If not, prepare to be pwned!

ok i will make my wordpress permissions strict. i don't want to be pawned in the future. thanks again!

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct