Cant pass the file directory permission test

This seems like an odd bug. You'll probably need to debug this yourself.

Following the instructions by the Security Review module, I began setting all folders and files to chmod 644 as instructed in the header/intro text on the file directory permissions test admin page. Clearly that is not correct as it basically shuts down the site. Removing "execute" from index.php and other permissions on folders like includes causes this error (good thing I didn't keep going or it would have been more effort to undo it):

Warning: require_once(/.../includes/bootstrap.inc) [function.require-once]: failed to open stream: Permission denied in /.../index.php on line 19

Fatal error: require_once() [function.require]: Failed opening required '/.../includes/bootstrap.inc' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /.../index.php on line 19

Any advice on this or should I just use my brain and not blindly follow this module's advice?

My guess is you have a mismatch between the user and group that owns the files, and the user and group which the webserver runs as. See this doc for examples of how to properly configure file permissions https://drupal.org/node/244924

Thanks Cash, will give it a read and see what I can do.

I don't know if I can add anything, but I can certainly confirm the same message as dean. However the list of directories and files that are writable just won't clear (flushing every time) despite permissions being correct.

I have shared Linux hosting and for now I'm assuming that the owner/server are being seen as the same...tbc.

Did you you resolve, dean?

For info;
I'm the only admin/user, the only one with access to the server, and no other access is allowed to any other group/future-user in the global Drupal permissions admin menu.

I've checked and re-checked all my permissions; everything corresponds to (or is more restrictive than) the conversations in the permissions discussions node. If I tighten them down any further the site collapses, and I've done this one file at a time, returning access after each failure.

Permissions issue that could be connected: I also have a message that the .htaccess file is writable. Even if I set the perm to 444 or 404 the message stays the same, which in theory is impossible as no-one can write.

CashWilliams, I'd guess that my site's account on my server has a different user than my root or primary server user and I can't see that being safe to grant one account to run as root, but I don't really know enough about all that to know for sure.

alsass, I pretty much undid the damage done by following this module's directions and stopped there until I could find out more as I really don't want to bring my server down or have to rebuild an account.

Pretty much all of my files appear in the "Executable PHP in files directory" when I run security check.

I checked with a friend of mine who does Drupal full-time.

She said the file permissions should be:
Folders - 755
Files - 644
settings.php - 444

I started randomly checking the files through my FTP server - every single one of them had the appropriate file permission.

Should the file permissions be something else?

je1654: File permissions do not necessarily decide whether the file can be executed by the web server. If a web server has read access to, for example, a .php file, it can read its contents and pass them to a PHP interpreter. The .php file itself is not executed, but the code within it will be executed by the PHP interpreter.

The web server configuration determines whether PHP files can be executed by the web server. If your web server is configured so that it uses the default .htaccess at sites/default/files/.htaccess, PHP should not be executable in the files directory. I am guessing your web server is misconfigured or the default .htaccess missing. See https://drupal.org/node/615888.

Hi

I have install security review 7.x-1.x-dev
I have a commerce kickstart site on a managed VPS server.
I have no access to root
Let's say I have my username 'greg'
And my own group which has the same name as my username 'greg'.
My folders and files permissions are set as following:
In public_html directory
d rwx r-x r-x greg greg ... folders/ and subfolders/ (755)
- rw- r-- r-- greg greg ... files files in subfolders (644)
...
In public_html/sites/default/files directory
d rwx r-x r-x greg greg ... folders/ and subfolders/ (755)
- rw- r-- r-- greg greg ... files and files in subfolders (644)
Ihave set the settings.php (444)

The issue is that the Security review is listing under 'Some files and directories in your install are writable by the server.' entirely all files in root (public_html)
Exept this, All the others security review check points are fine.

I cannot change my user group 'greg' by 'apache' or 'www-data' as suggested in drupal.org/node/244924
Maybe someone knows how to deal with such a server configuation to pass security check for files permissions?

Salif:

Which system user is your web server running as? If it is running as "greg", Drupal would have the same permissions as the files/directories owner "greg". Normally, the web server runs as a separate user (e.g., "apache"). You can add the following to index.php to check:

  echo exec('whoami');

If it is a user other than "greg", perhaps there are some files/directories within your Drupal root directory that improperly have user or group write permission. You can use this command from your Drupal root directory to check:

find -perm /go+w -ls

Hi
@ AohRveTPV thanks for your answer.

After I follow your instructions:
first: I found that my web server is running as 'greg' user

Second: I found that By default, Boost caches files in the cache/normal directory in document root, and the server has to access the cache/normal directory. The permissions are set automatically any time a new directory or file is created by boost:
cache/normal and all subfolders 775
files in all directories and subdirectories are set to 664.
These are certainly files/directories within your Drupal root directory that improperly have user or group write permission?

Maybe I must replace the boost cache elsewhere but not in document root? But how?

first: I found that my web server is running as 'greg' user

With file permissions 644 and directory permissions 755, and "greg" as the owner of those files/directories, "greg" will have write permission to all files/directories. Drupal will also have write permission to all files/directories, since it as running "greg". So the Security Review check will fail.

Best practice is for the web server to run as a different user than the user that logs in via a shell to maintain the site. If you log in as "greg", then the web server should run as a different user, such as "apache". This would get you a lot closer to satisfying the security check. A user "apache" would only have the permissions 4 and 5 on your files and directories.

Second: I found that By default, Boost caches files in the cache/normal directory in document root, and the server has to access the cache/normal directory. The permissions are set automatically any time a new directory or file is created by boost:
cache/normal and all subfolders 775
files in all directories and subdirectories are set to 664.
These are certainly files/directories within your Drupal root directory that improperly have user or group write permission?
Maybe I must replace the boost cache elsewhere but not in document root? But how?

I am unfamiliar with Boost. Maybe someone else will have advice. A possible solution other than relocating the files would be to change the umask of the user that generates the Boost files. That way the files could be created with permissions 755 or 644, for instance.

I think your main problem is that your web server is running as the files/directories owner "greg", who has write permissions. By solving that you could incidentally solve the Boost problem.

Hi
thanks for your answer, AohRveTPV
that means, If I want to secure my site, then I need to separate the webserver from the content owner.
I've tried these commands in shell
chown -R greg:www-data .
chown -R greg:apache .
chown -R greg:nobody .
but none of them is permitted even with sudo.

Is there any other ways to do that if I have no access to sever root?

Yes, exactly. If you can run the web server as a different user than "greg", that would solve the problem. Or if you could copy your web files using a second user so they are owned by that user, then run the web server as "greg", that would also solve the problem.

For what it's worth, on a typical Linux system (I do not know which platform you are on), when you start a web server like Apache using service httpd start or similar, it will be run as a user other than your current user.

It is possible that with your managed VPS you do not have a second user or generally have the freedom to make the necessary changes. You may need to contact the VPS provider for support.

Hi
@ AohRveTPV

Unfortunately, for the provider to maintain their policies on management of managed VPS server, run the web server as a different user than "greg" is not a change that can be made.

Now if I well understood:
The second option is:
First: let say that I have a user "greg" and a server running as "greg". I usually use that user "greg" to log in via a shell to maintain the site.
Second: Create a second user "joe" which is also a member of same server running as "greg" so that I could copy my web files using that second user "joe" so they are owned by it ("joe")

That means:

For public_html directory
d rwx r-x r-x joe greg ... folders/ and subfolders/ - 755
- rw- r-- r-- joe greg ... files files in subfolders - 644
...
For public_html/sites/default/files directory
As site involves uploading files, the following changes are required:
d rwx rwx r-x joe greg ... folders/ and subfolders/ - 775
- rw- r-- r-- joe greg ... files and files in subfolders - 644

sites/default/settings.php -444

Can you please correct me if I misunderstood something?
Thanks much

Yes, that is the idea. I would suggest some slightly different permissions, though:
- settings.php can be writeable by the file owner without any security risk, as long as the owner is not the web server user. So 644 would be as good as 444.
- settings.php would be more secure as 640, so your database password is not visible to other system users. (I do not think Security Review checks for this, but it is recommended elsewhere). Even if you have no other human system users, you may have system services running as other users that could be compromised.
- files in "files" directory may need to be 664 to allow writing by the web server.
- Since you have user-uploaded files, the "files" directories/files would be more secure as 750/640, so uploaded files are not visible to other system users.

The Securing file permissions and ownership page of the Administration & Security Guide is probably authoritative on the matter and probably worth a read. (It appears you might have already found it.)

Hi there,
I have same problem with my website, every time when i enter to my web site received this message
Warning: require_once(/home/siracorp/public_html/new/includes/bootstrap.inc): failed to open stream: No such file or directory in /home/siracorp/public_html/new/index.php on line 19

Fatal error: require_once(): Failed opening required '/home/siracorp/public_html/new/includes/bootstrap.inc' (include_path='.:/opt/alt/php55/usr/share/pear:/opt/alt/php55/usr/share/php') in /home/siracorp/public_html/new/index.php on line 19
How can i fix it??

Mahdy, are you using the Security Review module? The error does not look like a Security Review module error.

This page is for a Security Review module issue. The Security Review module is not a part of Drupal by default.

If you are not using the Security Review module, the better place for your question is probably one of the support forums. If you post your question there and provide a link I can try to help:
https://www.drupal.org/forum

If you are in fact using the Security Review module, I apologize.

Reading through comments, I cannot tell if this concern is resolved.

My site uses Drupal 7 on a managed VPS. Host does not allow the web server to run as a different user. All permission settings are correct per Security Review instructions, yet Security Review returns this message:

"The following files and directories appear to be writeable by your web server. In most cases you can fix this by simply altering the file permissions or ownership. If you have command-line access to your host try running "chmod 644 [file path]" where [file path] is one of the following paths (relative to your webroot). For more information consult the Drupal.org handbooks on file permissions."

Why does Security Review not see the permissions as they actually are? Is this what a false positive is? Or is there a bigger problem that needs to be addressed? Is there something else I can do to satisfy the Security Review?

Thank you!

~Catherine

The advice about 644 is only a good guess about the solution, but that advice is likely to be wrong on some systems.

If the user who owns the files is also the webserver user then 644 would be the wrong permissions. The docs have more advice, but 444 would be better in that situation.

Thank you, @greggles. If you meant 444 specific to settings.php, this is done.

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)

Closing as outdated after 6 years as we transition to Drupal 10.

I'm keeping an eye on the 7.x branch of this module, reviews and majors, but active work is going toward 42x (supporting D10)

If valid for 2.x please reopen