By rolygate on

Normally you get suPHP or you don't. Doesn't seem to make a lot of difference to Drupal but it might when installing plugins I guess.

We have an unmanaged dedibox with no suPHP. The host wants to install suPHP as it will make backups easier.

Anyone know if there are any issues with bunging that in on top of an existing Drupal 5x install?

⋅ Categories: Drupal 5.x

Comments

cog.rusty’s picture

cog.rusty commented

There will be a benefit for convenience and security (files and directories created by the server, such as uploads, will be owned by your own account and not by the server -- easier to handle), at the cost of somehow worse performance.

styro’s picture

styro commented

If you have a dedicated server, you don't need it to protect your files from other users/sites on the server as there aren't any.

And if you do use it, Apache now runs with the permissions of the file owner. This generally allows the website to overwrite it's own files.

So you get the main security risk of suPHP without the main security benefit.

rolygate’s picture

rolygate commented

Yeah, agreed, it may not be a great idea..... depending.

But we don't have a choice, the hosts are doing it to ensure the backups get all the files. According to them, some risk being dropped because of the ownership issues. This came about because cPanel have just changed their software, and some file backups crashed.

Anyway - all we need to worry about is if this will crash Drupal for some reason. I don't see how it can but who knows, maybe someone knows better.

styro’s picture

styro commented

But we don't have a choice, the hosts are doing it to ensure the backups get all the files. According to them, some risk being dropped because of the ownership issues. This came about because cPanel have just changed their software, and some file backups crashed.

I would've thought backups would be your responsibility on an unmanaged server ;)

Is there any way you can run a local backup script (as root) that then puts the backups elsewhere or at least somewhere they can pick up? A backup as root can then backup all sorts of stuff and allow you to restore the whole server (including all system file ownerships and permissions etc) in one hit.

But yeah, Drupal does run fine under suPHP/suExec type solutions - lots of shared hosts do that.

webel’s picture

webel commented

@styro wrote:

[with suPHP on dedicated] you get the main security risk of suPHP without the main security benefit.

That's my precise concern at the moment. See also my remarks under (closed) Security Review » Issues: Impossible for somephp configurations to pass the test for file system permissions concerning the now common combination of CentOS + suPHP on VPS setups.

Webel IT Australia, "Elements of the Web", Scientific IT Consultancy,
For PHP-driven Drupal CMS web sites, Enterprise Java, graphical UML, UML Parsing Analysis, SysML, XML.

davidlark’s picture

davidlark commented

... but if you're forced to live with it, here's the best info I've seen: http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-j... . It's mostly just a matter of changing permissions:

1. Check that the php script that you are attempting to execute has permissions of no more than 755 - 644 will work just fine normally, this is not something that will need to be changed in most cases.

2. Check that the directory permissions that the script resides within is set to a maximum of 755. This also includes directories that the script would need to have access to also.

3. Check that you do not have a .htaccess file with php_values within it. They will cause a 500 Internal server error, when attempting to execute the script.
The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the php directives as explained above.