I understand why suPHP is more secure, making PHP run as the current users instead of nobody or apache, but I’m realizing this then opens a security hole on the flip side. In order to be able to edit file via FTP, the website shell user must have access to the files, but then this also means that all PHP scripts on the site also have access to all the files. Normally this isn’t a problem, but if someone was able to hack a script on the server to run arbitrary PHP code, it could open and edit other files on the site. If it was running as apache it wouldn’t be able to edit files.
I’m not sure a good way to get the best of both worlds, besides logging in as root on the shell and setting everything to read only. Then if I want to edit file enable write and then turn it off when done. This doesn’t really work though for any clients that maintain their own websites.
The only other idea I have would be to make a special PHP user for each account. So account whatever.com would have shell users whatever and whateve2. Whatever would be the normal user that currently exist and wateve2 would be used with suPHP.
The problem with running scripts as Apache is that if someone was able to get shell access, then they could access any resources the Apache user can access (basically any other user’s PHP scripts).
Having all of your files set to read-only would probably be the most secure (by preventing unauthorized editing) but that would be a serious pain for your users. Running two accounts for shell/suphp access would likely result in a lot of configuration issues as all of your php scripts would have to be owned by whateve2 but grouped to allow the whatever user to create new files/edit new ones. You’ll also have to setup the “sticky bit” on the users directories to ensure that new files are created properly.
I hate to be “that guy”, but the best (and likely most unfeasible) solution is to make sure your users are uploading good code. Another option would be to configure PHP to disable many of the file editing/renaming/deleting functions (as well as exec), but that may break existing applications.
Unfortunately we don’t have a “bullet proof” answer this problem, but it’s someone we are always trying to improve upon. SuPHP isn’t a perfect solution, but in Shared Web Hosting there must always be trade-offs, and compartmentalizing a break-in to a single user is much better than allowing a break-in to potentially impact all accounts on the server.
Yeah, I actually did this in this case. It works even better since you can apply a php.ini file to each account separately.
Yeah, I agree overall the benefits of suPHP outweigh the other risk it introduces. I’ve actually wanted to use this for a while and glad I have it. I remember way back when there was some Apache mod that was trying to fork every apache process off as the user of the web account, but development stopped and it died out. Think it was called something like Per_Child.