New Ubuntu Linode, who should own /srv/www files?

If Apache is running as user and group www-data, any files and directories that Apache serves up should be owned by www-data:

chown -R www-data:www-data /srv/www/mysite.com/

-R makes it run the chown on mysite.com and anything inside it. www-data:www-data will change both the user and group.

NEVER have anything that's accessible outside your server owned by root. If these things are exploited somehow and owned by root, the person who did the exploit can easily gain control of your Linode. You also should avoid changing ownership to a user with ssh access since someone can try to get in with that user and brute-force (password-guess) your root password or (in the case of Ubuntu and with anybody who prefers using sudo over root) use your sudo access to mess things up.

Also, when possible, have your outside-facing services running as a dedicated user and the files served up by that service owned by the same user (e.g. a user without ssh access that is dedicated only to that service and nothing else, and with absolutely no privileges other than what's absolutely needed for that service). That's what Apache does, and for the same reason as above: if it's owned by a privileged user and that user gets hacked, whoever hacks it can gain control and mess things up.

Piki,

That is what I was thinking. Thanks for the confirmation!

@Piki:

If Apache is running as user and group www-data, any files and directories that Apache serves up should be owned by www-data
Nope. Nope. Nope.

Any files owned by www-data will be writable by Apache, and therefore by any PHP script. This might be OK if your forum software is 100% secure, but you can't be sure about that, can you? What if you're a few days late to update to the latest version? Exploited PHP apps have a nasty tendency to contaminate everything that is writable. Before you know it, there will be hidden footers on all of your pages with spammy links and cookie-stealing scripts.

In order to minimize damages if and when a PHP script gets exploited, as few files as possible should be writable by Apache. Most PHP apps require only one subdirectory to be writable. The rest of the website should be owned by a separate, non-root user. Simply changing the ownership will not prevent Apache from serving your files or running your PHP scripts, as long as you have reasonable permissions (755/644) on those files.

Edit:
@Piki:

If these things are exploited somehow and owned by root, the person who did the exploit can easily gain control of your Linode.
Only if those files are executable as root. Most website files are not. Guess who owns Apache's default "It works!" page? Root does. Even PHP scripts are always executed as www-data, regardless of who owns them. (It used to be different back in the CGI days.)

It's still better to have website files owned by a non-root user, though. That way, you don't have to log in as root to manage them.

@hybinet:

@Piki:

If Apache is running as user and group www-data, any files and directories that Apache serves up should be owned by www-data
Nope. Nope. Nope.

Any files owned by www-data will be writable by Apache, and therefore by any PHP script. This might be OK if your forum software is 100% secure, but you can't be sure about that, can you? What if you're a few days late to update to the latest version? Exploited PHP apps have a nasty tendency to contaminate everything that is writable. Before you know it, there will be hidden footers on all of your pages with spammy links and cookie-stealing scripts.

In order to minimize damages if and when a PHP script gets exploited, as few files as possible should be writable by Apache. Most PHP apps require only one subdirectory to be writable. The rest of the website should be owned by a separate, non-root user. Simply changing the ownership will not prevent Apache from serving your files or running your PHP scripts, as long as you have reasonable permissions (755/644) on those files.

If the php files are owned by a user that can use su or sudo, then that would allow that php to use su or sudo, correct? By default, on most Linux systems, all users can use su by default, and Ubuntu allows the default user to use sudo by default. However, if the www-data user that's created by the apache package doesn't have access to su or sudo, it can't access my root account or my own user that can use su or sudo, and in that case if someone does exploit my site and have spam links hidden in my footers, then deleting all php being served by www-data will fix the issue. Of course, that presents the problem of restoring the PHP, but having an unblemished backup owned by a completely different user or kept on another computer will solve that issue.

@Piki:

If the php files are owned by a user that can use su or sudo, then that would allow that php to use su or sudo, correct? By default, on most Linux systems, all users can use su by default, and Ubuntu allows the default user to use sudo by default.
A script could try running sudo all day long, but it won't succeed unless the username is in the sudoers file and the script knows the password. (There are ways to use sudo without passwords, but those are not enabled by default for a very good reason.)

Ubuntu's default user can use sudo, but AFAIK there is no default user in Linode's version of Ubuntu. Any user you create on a Linode (using the useradd command) is completely non-privileged. There is no difference between www-data and a new user in that regard.

Having web files owned by www-data is definitely better than having them owned by root. I don't dispute that. But you can make your server even more secure by creating a non-privileged user for each site and having them own their respective files.

Besides, if the files were owned by www-data, you'd have to log in as www-data (or even worse, root) in order to manage them. You would probably want SFTP access for www-data, or maybe even shell access. But it's a bad idea allow logins or give shell access to a user that runs a public-facing daemon. By default, www-data doesn't even have a password.

@hybinet:

@Piki:

If the php files are owned by a user that can use su or sudo, then that would allow that php to use su or sudo, correct? By default, on most Linux systems, all users can use su by default, and Ubuntu allows the default user to use sudo by default.
A script could try running sudo all day long, but it won't succeed unless the username is in the sudoers file and the script knows the password. (There are ways to use sudo without passwords, but those are not enabled by default for a very good reason.)

Ubuntu's default user can use sudo, but AFAIK there is no default user in Linode's version of Ubuntu. Any user you create on a Linode (using the useradd command) is completely non-privileged. There is no difference between www-data and a new user in that regard.

Having web files owned by www-data is definitely better than having them owned by root. I don't dispute that. But you can make your server even more secure by creating a non-privileged user for each site and having them own their respective files.

Besides, if the files were owned by www-data, you'd have to log in as www-data (or even worse, root) in order to manage them. You would probably want SFTP access for www-data, or maybe even shell access. But it's a bad idea allow logins or give shell access to a user that runs a public-facing daemon. By default, www-data doesn't even have a password.

Or set the group of the files to www-data and give it only read permission.

@hybinet:

A script could try running sudo all day long, but it won't succeed unless the username is in the sudoers file and the script knows the password. (There are ways to use sudo without passwords, but those are not enabled by default for a very good reason.)

Brute force attacks through su or sudo ;-)

@hybinet:

Ubuntu's default user can use sudo, but AFAIK there is no default user in Linode's version of Ubuntu. Any user you create on a Linode (using the useradd command) is completely non-privileged. There is no difference between www-data and a new user in that regard.

I thought Ubuntu has the root user locked out completely and required sudo for doing root-only stuff? In my few experiences using Ubuntu, I never tried to su to root, but I'm fairly sure I read somewhere that this was the case.

@hybinet:

Having web files owned by www-data is definitely better than having them owned by root. I don't dispute that. But you can make your server even more secure by creating a non-privileged user for each site and having them own their respective files.

Hmm… 8 sites, 1 person to remember 8 users and 8 passwords for those 8 sites… my brain hirtz already!

@hybinet:

Besides, if the files were owned by www-data, you'd have to log in as www-data (or even worse, root) in order to manage them. You would probably want SFTP access for www-data, or maybe even shell access. But it's a bad idea allow logins or give shell access to a user that runs a public-facing daemon. By default, www-data doesn't even have a password.

Of course www-data shouldn't have shell access! :-)

You do have a point: if my brain could remember 8 users and 8 passwords, and I hacked up my system to prevent those users from using su (or at least using su to switch to a privileged user or one of the other 7 users), then that would be more secure than using www-data.

The lazy man's workaround: Disable passwords and root logins in ssh and use an obscure passphrase on one's ssh keys ;-)

The ownership of the files has absolutely nothing() to do with the user that executes the files. That is entirely() determined by the user Apache is running as, i.e. www-data.

www-data is not in your sudoers file. www-data should not have a password. You should not be able to log in as www-data. However, everything your web server might conspire to execute will run as user 'www-data', no matter who owns it(*).

From this, it's fairly clear that you want as little stuff as possible owned by www-data. In fact, I'd say anything that must be owned by www-data (or set chmod 777 or whatever they're telling kids to do with scissors and untied shoelaces and boxes of glass these days) is absolutely broken (this means you, self-upgrading PHP applications). Self-modifying code is dangerous stuff(**).

Only downside to making stuff owned by root is that you'll need to be root (or futz around with groups) to edit the files. So, I figure owning the files yourself works out well.

(*) except in some particularly rare cases that don't apply here

(**) there are usually alternatives that work out better, e.g. wordpress via SVN. Alas, you'll need to use your keyboard to upgrade Wordpress, but it's a small price to pay for not running around a blackberry patch without metaphorical pants.

@Piki:

I thought Ubuntu has the root user locked out completely and required sudo for doing root-only stuff? In my few experiences using Ubuntu, I never tried to su to root, but I'm fairly sure I read somewhere that this was the case.

You do have a point: if my brain could remember 8 users and 8 passwords, and I hacked up my system to prevent those users from using su (or at least using su to switch to a privileged user or one of the other 7 users), then that would be more secure than using www-data.
Ubuntu Desktop Edition behaves as you described. The root user is locked out, and the first user you create during installation gets to use sudo for all administrative tasks. Additional users are non-privileged by default.

On a Linode, Ubuntu behaves just like any other reasonable distro. The root user is enabled by default, and any additional users you create are non-privileged by default. You don't need to do anything special to prevent them from using su.

This is how I usually arrange web stuff in Debian/Ubuntu:

• Disable root SSH login.

• Create a privileged user for myself, with strong SSH keys. This user does not own any web stuff.

• Create one non-privileged user for each website. (Or for each group of websites, if they're closely related.) Add my SSH public key to all of them.

• Run the web server as www-data.

• PHP runs either as www-data, or as each user. (FPM rocks!)

• I can log into any website by simply typing "ssh username@hostname" at home, or even more simply by tweaking ~/.ssh/config. Password is only necessary the first time I use a private key, because my private keys are tied to my desktop login session.

@hoopycat:

www-data is not in your sudoers file.

Obviously.

@hoopycat:

www-data should not have a password.

Doesn't need one.

@hoopycat:

You should not be able to log in as www-data.

Default when created by the apache package.

The point I'm trying to make is that if a user can use the su command and he doesn't specify a user when using su, it automatically assumes that the user wants to su to root. Any user that owns scripts (PHP or otherwise) should not be able to use su for that reason, so I don't feel safe having my PHP owned by a user that can use su. Since www-data is created without a password or the ability to be logged in to, I was under the impression that www-data was (by default) setup to be locked out from the su command by default?

@hybinet:

On a Linode, Ubuntu behaves just like any other reasonable distro. The root user is enabled by default, and any additional users you create are non-privileged by default. You don't need to do anything special to prevent them from using su.

Most of the distros I've used aren't reasonable purely from the standpoint that all users can use su, but they will never successfully use it if they don't have the password of the user they want to su to. I'm running Debian on my Linode, and I have several other users that have reported that su does prompt them for a password, but they coulnd't su because they didn't know the password. I did nothing to enable su for them.

@Piki:

The point I'm trying to make is that if a user can use the su command and he doesn't specify a user when using su, it automatically assumes that the user wants to su to root. Any user that owns scripts (PHP or otherwise) should not be able to use su for that reason, so I don't feel safe having my PHP owned by a user that can use su. Since www-data is created without a password or the ability to be logged in to, I was under the impression that www-data was (by default) setup to be locked out from the su command by default?

su doesn't require the current user's password (as opposed to sudo), so I believe it would work as well for www-data as it would for any other user.

It's tough to generalize because there's a lot of different su implementations. Some implementations require you to be in the 'wheel' group to su, others don't. All implementations require you to know the root password to su to root, though. (If www-data "knows" the root password, you've probably already lost the game.)

@Piki:

Any user that owns scripts (PHP or otherwise) should not be able to use su for that reason, so I don't feel safe having my PHP owned by a user that can use su. Since www-data is created without a password or the ability to be logged in to, I was under the impression that www-data was (by default) setup to be locked out from the su command by default?[/bquote]

You're missing the point. Who owns the PHP file is irrelevant in this context, that's just a permissions thing. Your PHP file could be owned by fred, but since it's www-data who executes the file, it will run with www-data's permissions.

The only thing that matters when it comes to execution is the user who is executing. The owner of the file only determines if the executing user can read the file to execute it.

The PHP script could be owned by root, and that would be no less secure than the script being owned by an unprivileged used.

Pixi might be thinking of suEXEC?

My web files are generally root:www-data and 750 on directories and 640 on files. There are exceptions for folders where web apps will download or create temporary files and those have to be 770.

If your web app is compromised the intruder will be able to do anything that the www-data user can do. You do not want your scripts to be owned or writable by www-data or the intruder could make subtle changes to your web app that you wouldn't notice.

You want to limit the amount of damage that the www-data user can do.

Just because you can't log in as a certain user (e.g. www-data) doesn't mean that the same user cannot execute any shell commands. Any PHP script running as www-data can execute any command (including su) using functions such as shellexec() and procopen(). A sophisticated script might even be able to run an interactive bash session. There's absolutely no difference between www-data and any other user in that regard. (By the way, it's not a bad idea to disable those functions in php.ini.)

@Piki: I think I misunderstood your second-last comment. I didn't mean to suggest that Ubuntu prevents users from calling su or sudo. What I wanted to say is that such calls will never succeed unless the users are in the sudoers file or they know your root password. Sorry if this misunderstanding caused confusion. (If your root has a weak password that anyone can guess, that's a different problem. I recommend that you remove the root password altogether, or use a very long string of random characters.)

The security of your server should not depend on preventing users from calling su or sudo. Users can call any damn thing they want to call, either from the shell or from a script. They can try "rm -rf /" all day long, but I don't care because those commands will never succeed. The important thing is to prevent them from using such dangerous commands successfully. All Linux distros, including Ubuntu, do this job very well by default.

@hybinet:

They can try "rm -rf /" all day long, but I don't care because those commands will never succeed.

With that specific example, I believe it depends on your definition of "success".

(It's been a long time since I've rm -rf /'d as a normal user, though. Unfortunately, I'm fresh out of whipping nodes since tentacoo-wape was deleted to cover Jelly of the Month Club memberships for all of my employees. Someone else will have to try it.)

@hoopycat:

@hybinet:

They can try "rm -rf /" all day long, but I don't care because those commands will never succeed.
With that specific example, I believe it depends on your definition of "success".
If nuking your own website while leaving the rest of the system intact counts as "success", then I can agree that rm -rf / might "succeed". Just another reason why website files should not be owned by the same user that executes PHP scripts.

In any case, it would be futile to try to blacklist every dangerous command. If you're really paranoid, you might want to chroot your users and whitelist a bunch of safe commands instead.

@hybinet:

Just because you can't log in as a certain user (e.g. www-data) doesn't mean that the same user cannot execute any shell commands. Any PHP script running as www-data can execute any command (including su) using functions such as shellexec() and procopen(). A sophisticated script might even be able to run an interactive bash session. There's absolutely no difference between www-data and any other user in that regard. (By the way, it's not a bad idea to disable those functions in php.ini.)

Worth noting that PHP-FPM SAPI disables the proc_* functions by default - the shell stuff isn't, however.