This module is great. Very helpful. Thank you.

I'm having trouble translating the recommendations regarding file permissions to my dedicated server (over which I have full control).

My server is running Apache Apache/2.2.16 (Unix) and PHP 5.2.14. It has the suPHP extension running. Here is how the techs at my server company describe what suPHP does:

the function of suPHP on your server is to run PHP scripts as your cPanel user rather than as "nobody," the user account that Apache runs under. This allows for more secure permissions for PHP files and will prevent any PHP files with world-writable permissions from being run. Most files can have permissions set to 644 and most folders should have 755 permissions.

It seems that if suPHP is preventing any file with world-writable permissions from being run, then that would cause the security_review module to report back, incorrectly, that certain files need to have their file permissions changed in order for the Drupal set-up to be secure. Is that true? Should I just ignore those recommendations on the security_review report?

Or to ask more generally, how does the existence of suPHP installed on my server affect the recommendations made by the security_review module?

Is suPHP just serving to protect site owners with insufficient knowledge of file permissions from themselves? Or does it really add something of value, regardless of the site owners knowledge and implementation of best practices for file permissions?

Thanks so much,

Shai

Comments

Shai’s picture

Shai commented

As an enthusiastic user of this module... I'm interested in a response to my question.

Thanks much,

Shai

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

The problem is not running files that are world writeable. The problem is running files that are editable by the webserver.

I created #1153486: Attempt to create a file and modify a file to confirm file permissions as a way to confirm whether the webserver can read/write files that could potentially be executed by the server itself.

As an enthusiastic user of this module... I'm interested in a response to my question.

Speaking only for myself: this comment feels a bit aggressive. The module and advice related to it are not easy to give. Your question required additional research and time on a machine with a similar setup. I appreciate that you are an enthusiastic user, but that doesn't create time in my schedule to prioritize giving free advice on top of a free module.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Fixed

Marking fixed for now. Feel free to re-open (or discuss in the other issue) as you see appropriate.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Duplika’s picture

Duplika commented

I want to add my comment on this, but won't open the status to avoid taking time from the developer, which I greatly appreciate.

suPHP as Shai said, is a popular PHP handler among us hosters, to offer a better security against outdated and unsecure applications, which most of the Internet users have.

With suPHP, we haven't found a way to avoid the mentioned warning, so it's basictly suggesting that suPHP is an unsecure environment, which might mislead some people.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

As I understand it the problem is somewhat about where you have your priorities. Hosting companies prefer suPHP because it limits vulnerabilities to a single site. It makes it easy to rapidly exploit and escalate to code execution vulnerabilities in that site, but it limits them to that site. The vulnerability cannot be used to exploit another site on the same host.

The position of this module, and the Drupal project in general, is that it's unacceptable to allow for this kind of modification of the code running the site.

I do not believe your claim that it is impossible to avoid the warning. Consider this setup:

  • An account for exampleuser in the group examplegroup
  • An account for exampleuserphp which is also in the group examplegroup
  • exampleuser is the owner of all files in the site with read and write permissions
  • examplegroup is the group for all files in the site and only has read permissions with the exception of the "files" directory where it can also write
  • suPHP runs as "exampleuserphp" for the site

I believe that scenario would maintain the per-site permission issue that hosting companies want to control AND provide the security within the site that is the standard in the Drupal project.

The drawback to my proposal is that file permissions are confusing to end users and letting suPHP run as exampleuser makes it easier for these users to maintain their sites even if it makes them slightly less safe. Hosting companies like to make things reasonably safe AND easy to maintain to reduce support requests.

sandip choudhury’s picture

sandip choudhury commented

Hello,

I have just purchase an unmanage dedicated server and install control panel Kloxo-MR. In control panel there is an option for choosing PHP Type -

mod_php_ruid2
mod_php_itk
suphp
suphp_event
suphp_worker
php-fpm_event
php-fpm_worker
fcgid_event
fcgid_worker

Which PHP type is the best for Drupal?

aohrvetpv’s picture

aohrvetpv commented

Sandip, I think this is a general Drupal question that is not related to this specific module. Perhaps opening a support request on the Drupal project (https://drupal.org/project/drupal) would be more appropriate.

webel’s picture

webel commented

For those who are considering setting up a single user Apache+CentOS+suPHP+cPanel system you may wish to inspect my forum posting collating some reference links relevant to this topic; Support » Installing Drupal: SECURITY CONCERN: reference links: suitability for Drupal CMS of Apache+cPanel+suPHP on single user system (VPS or Dedicated)