Web server file system permissions

Hi Starminder, the most recent dev release of Security Review contains expanded information on this check and what to do. It links to a Drupal.org handbook page http://drupal.org/node/244924

Should be available right now according to http://drupal.org/node/622692 or I will probably have a stable release out in a couple weeks at the latest

I have a huge listing of files that have incorrect permissions, like "./xmlrpc.php" -- but I'm wondering if those are just hidden Mac files, since they all start with a period? Hope that's not a stupid question...

Oops, forgot to re-open the issue.

lrobeson, items that are listed as starting with "./" are not hidden. "./" means the current directory so "./xmlrpc.php" is the file "xmlrpc.php" in the current directory. The module searches for writable files starting from the web root directory which is most often the root directory of your Drupal installation. In this case the file "xmlrpc.php" as part of your Drupal installation (Drupal's XML-RPC responder) is reportedly writable by your web server and should be corrected. As well as other files listed.

Hope that helps.

I guess this is fixed. One idea would be to remove the "./" from the beginning of the listing. While the ./ makes sense to me I think it's fairly uncommon to see files listed with a ./ in front of them.

Hey Greg!
Found this wonderful module just today... and boy, it seems I might be heading for trouble.

See I also have an impressive list of files with wrong permissions. My problem is I can't figure out the right ones.

Take index.php for instance. I changed it from 644 to 640. Ran again the checklist and it still appears as in danger.

And I still have a very long list of whole modules and core files in the same situation... :-(

Any advice, apart from http://drupal.org/node/244924 ?

Warm regards!
Pepe

Hi Pepe - that page tries to describe how there are two important characteristics, the file permission and alsot he file owner. My guess is that your webserver runs as a user who is also the file owner. That is why a permission of 6 for the file owner lets the webserver modify the files.

Hmmm...
So there is nothing I can do? Except have a little chat with the hotdrupal guys, maybe...:-)

Wonderful module (think I already said that), that helped me fix some other issues... :-)

Warmest regards from sunny México!
:-)
Pepe

Hi - thanks for this useful module.
My only concern is that it's reporting a huge list of files in my various "files" directories, which are appropriately set to be world-writable, as being a problem.
Could there be a way to give the module a list of "files" directories to ignore?
(I have more than one "files" directory, because I'm hosting multiple sites on one Drupal codebase, and they all each need their own "files" directory).

Hi Sam, the module checks if a directory is the Drupal files directory and ignores it, but in the cause of multi-site it will fail for other sites' files directory. Let me think awhile on check-level configuration options, but for the time being you could choose to ignore the entire check if you like.

Hi Pepe, in regards to your comment in #11 it sounds like you need to change the owner of your files and directories under Drupal. If you have shell access you can use the chmod utility. If you're unsure I would contact your hosting provider.

Thanks, Ben!

Warm regards!
:-)
Pepe

@coltrane - thanks. Post again if I can help with this. I'd be happy to test for example.

Hi, everyone, I used this module yesterday and was glad I ran it. I corrected the things I understood, but much of it was questionable for me.

Since my users are able to upload images, I had to leave img tag in the Input Format. I'm not sure what the ramifications of that are.

But the thing that most concerns me is that I too got a very long list which included all my core modules, core themes, drupal core, etc...

So what am I doing wrong? I am happy to change my file permissions.... if I understood them better. I have read and read related posts, but it hasn't clicked yet and I'm afraid my files are wide open for the world to see.

btw - I have installed Drupal 6.15, I run on Dreamhost and am using the Marinelli theme.

Thanks for any help!

I just downloaded the dev version of the module with the date of 2009-Dec-08 and I am also seeing this problem with many Drupal core files showing on the listing. I wonder, do I just need to wait for the new dev version to show up?

Thanks. This module looks very useful.

Please note, the module is not 100% accurate in determining pass/fail on checks, but it is more likely that your files and directories are incorrectly owned or permissioned than this module being buggy.

It seems like more documentation is required to explain the check, but I recommend you reread the help documentation provided on the details page for the web server file permissions check for the time being.

Sadly, the area that I (and all webmasters) need to know about most, is what I understand the least.

I just don't get the file ownership/permissions and I wish there was better documentation for the Security Review module. Getting a list of 100 files does not help me, if there are no suggestions on what to do about it.

I'll re-run the check and see if anything has changed. Thanks for the suggestion on rereading the help documentation, I probably missed something there.

@guitarma, sure, I understand your frustration, the documentation is obviously not enough, I'll try and work on that soon. In the mean time you may have some luck with searching for general help on server file permissions to better understand why you need to be concerned with write access.

It's nice to know I'm not the only one struggling to understand server file permissions and Drupal.

Thanks very much for this module, it is useful for a number of items and has helped to bring me back to a closer re-examination of this subject.

I am not sure if it is better for me to share my thoughts here in this issue or as a comment on the Drupal handbook page, if anyone cares to suggest.

Meanwhile, from what I can grasp so far there appear to be possibly two scenarios, although this may only reflect my current ignorance. Please jump in and correct me wherever you can.

The first is a development environment where modules may be added and changed frequently and a production site where the file permissions need to be locked down further.

I have tended to leave it to Drupal to set the file permissions itself and so was quite surprised to see so many identified as not secure. During this I have seen a few permission settings that are common. 755, 644, 600, 555, and 444.

From playing around with this module it seems that it is essentially promoting that a secure site for files in all folders, except the domain/files folder wherever that resides, be set to 444 and all folders themselves be 555 or 551.

I am not sure whether it is better for folders to be 555 or 551.

I had previously thought from the Drupal installation that folders were okay as 755 and only some specific files needed to be 444 or 600. But that is what this module draws attention to.

Clearly to make site wide permission changes it is best to use shell commands and it may only require two.
1. To change the permissions of all folders to 555 or 551
2. To change all files to 444
Except of course the domain/files folder and contents which requires further work.

The Security Review module provides a helpful link to the Drupal handbook page and included in a comment is the following:
# find . -type d -exec chmod u=rwx,g=rx,o=x {} \;
that presumably will change all folders to 751.
Should this be changed to make the folders 551 or 555 ?
And is this correct to change all folders recursively ?

Presuming my assumption above is correct that all files need to be changed to 444,
what command would be needed to recursively change all files to 444 ?

I hope others can help here.

Thanks,

Izzy

I'm still not sure if it is correct of me to continue this discussion in this issue rather than somewhere else. Please excuse me if this is wrong and let me know.

One other specific consideration might be the file ./error.log

The Security review module checks to see if any write permissions exist and expects them to be off. which isn't entirely clear to me as I thought the server processes would also need to be able to write to this file.

I also wonder if "other" even needs read permissions or could have no read, no write and no execute for other. So I wonder if "440" might be more ideal.

Izzy

I really appreciate your post, Izzy, thanks for your input. So I asked the files permissions & Drupal question on my host's forum yesterday and got this reply:

Leave the file permissions alone. Postings to Drupal are stored in the database, not in the site directory, so the file permissions have no effect whatsoever. Everything you're after is controlled by the permissions settings within the Drupal application.

What?! Is that true and have you ever heard that?

The reason you do not want writeable files in the file system is because of the possibilty of another vulnerability in your web application or on your site being exploited so that a malicious user could take advantage of the insecure file permissions to store and execute evil code.

Follow me on this, you know how you have to make your [site]/files directory writeable? Like when you install Drupal you have to make the directory sites/default/files (or similar) writeable, right? Well, Drupal is smart enough to make sure that any file ending in .php (a PHP file) under your [sites]/files directory cannot be executed. If Drupal did not do this, a malicious user could upload a PHP file to this directory and possibly get it to execute. This PHP file could do something like print all the passwords of the users on your site, or send out spam email, or worse. Drupal protects that from happening, but the [sites]/files directory. Why doesn't it protect everything else? Because we want Drupal's (and only Drupal's) PHP to execute. We do not want malicious person's PHP to execute.

So, you want the only place that Drupal can write files to to be a place that cannot execute PHP, right? You have to alter the file permissions of your Drupal install. And you are safer if you alter the file permissions of anything under your web root. For instance, if you install Drupal in a subdirectory of your host so that you access your site at www.example.com/drupal, you are safer if you also limit the write permissions on the root directory, www.example.com/ in this case.

I hope that starts to shed some light on this complicated subject. It's hard to explain and I can't yet put together a really good explanation. I encourage you to do some searches on the topics of apache process user and server file permissions. This whole subject is about limiting the write permissions to certain users, the user who owns the file (often times the apache process user), the group the file is in, and other (a.k.a world) users.

@guitarma You're welcome, but I hope you realize I am providing more questions than answers.

So far I have found that making changes to the file permissions as suggested by the Security Review module has not caused any problems with the operation of the site I have been trying this on.

I don't know if this is actually making the site more secure but since my level of knowledge in this area is fledgling at best I am willing to accept it may be better and hope to further my understanding.

However, it does add the extra requirement to temporarily change permissions to permit write whenever the site requires updates of any contrib modules and changing the permissions back to satisfy Security Review. So, it would be nice to know that this is worth doing for security reasons and not just adding extra tasks or steps for nothing.

Previously, I was leaving the settings as they were and didn't have this extra step and in my ignorance was content to trust that Drupal was taking care of all the file permissions. Although, now I am not sure that Drupal takes care of any other than a few basics pertaining to the settings.php files, the specific sites folders and the files folders. The other file permissions might just be some server defaults and may be great for starting but not best for production. Still more to learn.

Izzy

I think I just need to pay someone to do it for me. I would rather spend my time building a bitchin' Drupal site and know that an expert has it taken care of, than dreaming of bad file permissions every night - hahaha!

So who wants to make some money...??

guitarma, Growing Venture Solutions provides security review for Drupal sites, including configuration of file system permissions. Feel free to contact us through http://growingventuresolutions.com or my Drupal.org contact form.