Community

Security risk with "chmod 777 files" versus "chmod 755 files"?

I'm enjoying my very first taste of Drupal, trying out my brand-new installation. After some searching (and swearing) I found that the reason I couldn't upload files was that I needed to create a files/ directory and give it the right permissions. Now, I find that with permission 777, everything works fine. With 755 (or 775) I get the message:

The directory files is not writable.

in my administer >> settings view, and trying to upload files (for instance attaching a file in "Edit content") results in:

  • The directory files is not writable.
  • File copy failed: no directory configured, or it could not be accessed.

According to this comment, 777 is an extremely bad idea, security-wise. Can anyone confirm or deny this?

And if it is such a bad idea, is there some alternative solution to my problem with uploading files?

Comments

In my case, and possibly yours also, I am the owner of the directory files. To allow the webserver write access to this directory I have to give group/world write access hence the 777.

To limit the ownership to 755, the webserver user id, should own the directory files. To to this, the upload module (I think) should be updated to automatically create the directory with the appropriate permissions.

A simple check box could be added to the settings requesting permission to create the folder. There may be a good reason for this not already existing.

Paddy.

http://deburca.org, and http://amadain.net

Thanks!

Thanks!

So you're saying that if I want to use 755, the webserver needs to become the owner of the directory files. Right? Is this something I can specify myself?
I'm sharing a server with a lot of other people, and probably can't (or shouldn't) do changes that affect other users.

I'd appreciate some info on whether setting the permissions for that directory to 777 is insanely insecure or not. It does seem like the easiest way out, but if it's too insecure I'll just have to find another solution.

The quick answer - 777 is insanely insecure - but

A 777 permission on the directory means that _everyone_ has access to read/write/execute (execute on a directory means that you can do a ls of the directory).

There is also a nice thing called a umask. (if my memory serves me right) The umask, of 022 for example, would create new files with the 755 permission. This means that your http deamon could create files where only the deamon has write access and everyone else only has read/execute access. Check out man pages for chown and umask for more information.

Paddy.

http://deburca.org, and http://amadain.net

Thanks, I'll look into that.

Thanks, I'll look into that.

as far as i understand it,

as far as i understand it, *everyone* having permission doesn't include the average joe on the internet, but only everyone who has an account or access to that machine.

if the machine is:

* on a shared hosting solution
* has anon ftp access or a number of other entry points the general public can use
* is a workstation that many people log into

then 777 is a bad idea.

but if you've got a reasonably locked down dedicated server with no user accounts other than your own, 777 shouldn't pose any more security risk than anything else. there'd have to be some other vulnerability for a malicious user to take advantage of that, and at that point, the 777 permission is probably moot anyway.

feel free to correct any inaccuracies in the above; i'm not a unix guru by any stretch of the imagination, but it's my understanding 777 doesn't just mean some random joe can laser all yer stuff if they don't have an account of some sort on the machine.

Ah, that's good to hear. I

Ah, that's good to hear. I know enough about IT to have an idea of how horribly things can go wrong (and that the weakest link in any security setup tends to be the users), but Unix is a mostly foreign country for me.

I am on a shared hosting, but it's shared within a small, relatively transparent group, so I'm not that worried. And after a tip from another user on that host, I found that 703 worked as well. (At first I thought that when it didn't work with 755 it wouldn't work with any lower numbers, but that was before I realised that the notation is shorthand for a series of three-digit binary numbers.)

thank you

thank you. That's a good way of putting it.

Shared server and mode 777

The problem is really that the files have to be written by the web server so any script run by the web server can read/write/delete these files. So, if anyone else can install php scripts on to the same server as you are running you Drupal site on then they can, very effectively, shut down your site.

Does anyone know how to prevent this?

I have not created a 'files' directory and will not do so until I can find a way of making things more secure.

I just installed drupal for

I just installed drupal for my first time on a shared server, and I seemed to have gotten around this by changing the chmod of the installation directory to 0777 then running a php script to create the "files" director, with a chmod of 0755. Then change the installation chmod back to 0755.

does this cause errors

> ... 777 ... 755 ...
does this cause errors later to switch it after Drupal checks?

and does the 703 actually work?

I can't get filezilla to

I can't get filezilla to change the permission... it keeps coming back with...

CHMOD 755 default': command not understood

I contacted godaddy and they said it was a drupal issue. Any help ending this error message would be appreciated!

Configuration file Not protected
The directory sites/default is not protected from modifications and poses a security risk. You must change the directory's permissions to be non-writable. The file sites/default/settings.php is not protected from modifications and poses a security risk. You must change the file's permissions to be non-writable.
Cron maintenance tasks Never run
Cron has not run. For more information, see the online handbook entry for configuring cron jobs. You can run cron manually.

I got it to work! Thanks for

I got it to work! Thanks for all the help everyone! I just went to godaddy.com and switched my served from Windows to Linux, and it now allows me to write the permission levels in filezilla!

I would recommend just starting out with the Linux version (as I was originally directed and refused) instead of Windows....it really is much better.

The only other problem I'm having is this error

* warning: fopen(sites/default/files/.htaccess) [function.fopen]: failed to open stream: Is a directory in /home/content/s/h/a/shanklinmike/html/includes/file.inc on line 129.
* Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your sites/default/files directory which contains the following lines:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

in the theme configuration page. I can't even change the color of my website and nor can I save pictures images. Thanks once again for all your help!

Windows vs Linux

Good to hear you got that working. I've been using Windows from the my beginnings with Drupal, but I've been on local machines. On hosted websites, I've always much preferred Linux installs. (I'm sure I would prefer Linux locally, as well, but I've only had the "luxury" of working with Windows machines.)

Yeah, linux works much better

Yeah, linux works much better for me...hosting wise at least....I get this on my theme configuration settings page:

* warning: fopen(sites/default/files/.htaccess) [function.fopen]: failed to open stream: Is a directory in /home/content/s/h/a/shanklinmike/html/includes/file.inc on line 129.
* Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your sites/default/files directory which contains the following lines:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

Any suggestions?

Thanks man

open_basedir

The shared hosting solution I know (Plesk) uses PHP's open_basedir feature to restrict where PHP scripts can write to. For instance a script run on domain1.com can't write to dirs under domain2.com's httpdocs folder, even though they may be chmodded 777.

From my experience

777 allows anyone to access and write to files. This is similar to allowing the IUSR on a Windows machine to have write permissions.
I could be wrong, but I'm fairly certain that's what it's like.