By zirvap on

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?

⋅ Categories: Drupal 4.6.x

Comments

paddy_deburca’s picture

paddy_deburca commented

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

Paddy.

http://deburca.org

zirvap’s picture

zirvap commented

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.

paddy_deburca’s picture

paddy_deburca commented

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

Paddy.

http://deburca.org

zirvap’s picture

zirvap commented

Thanks, I'll look into that.

hedgehog’s picture

hedgehog commented

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.

zirvap’s picture

zirvap commented

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.)

kae’s picture

kae commented

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

Graham Rule’s picture

Graham Rule commented

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.

jimwright’s picture

jimwright commented

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.

Zachariah’s picture

Zachariah commented

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

and does the 703 actually work?

mikeshanklin’s picture

mikeshanklin commented

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.

mikeshanklin’s picture

mikeshanklin commented

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!

dambrisco’s picture

dambrisco commented

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.)

mikeshanklin’s picture

mikeshanklin commented

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

breun’s picture

breun commented

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.

dambrisco’s picture

dambrisco commented

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.

hyperlinked’s picture

hyperlinked commented

I'm sure this issue has long passed for the OP, but I'll add to it since a lot of people get tied in knots about 777 vs 755 in some hosting setups. You may have had some sites on some hosts that work fine with everything issued under 755 grants and on other hosts, you have to use 777 grants on some common directories and files. So why the difference?

Some hosts have the same user running PHP as the one running FTP. That means if "user1" owns the FTP files, "user1" also executes apache, php, and other operations. Since these are the same user, it's basically like giving a 777 grant on a system in which PHP and FTP are handled by separate users.

If you have an insecure script and I hack into it and I start modifying files. I'm whatever user that is running that script. If everything is owned and run by the same user, then it won't matter if you have your permissions set to 700. The only thing that really matters at that point is the first "7" because the intruder has broken in as the owner and runner of all of your files.

As hedgehog said, 777 is a more relevant issue when you're in an environment where other users could potentially have access to your files and directories because other users on that server could make modifications to your filesystem. That would mean if one of your neighbors was running an insecure script and was broken into, the hacker could get into your files through that neighboring account.

Most shared hosting environment have compensations in place to prevent your neighbors from wandering into your file directories though. Breun brought up Plesk's use of open_basedir, which prevents PHP from reading or writing outside of restricted directory path.

This isn't to say that you should just by default change everything to 777 because it won't matter anyway. Don't give out an ounce of access more than you have to just in case the unexpected happens. I'm just saying that if you have to resort to a 777 grant, it may not be as bad as it looks and if you feel safe and smug because you're running everything with a 700 grant but all files and processes owned by the same user, your sense of security is unfounded.