Security risk with "chmod 777 files" versus "chmod 755 files"?
zirvap - December 4, 2005 - 13:54
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?
It is 777 as you are the owner of the directory no the webserver
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?
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.