By tengo on
Hi I am running my drupal 5.1 on a linux server.
I have just completed my migration from an old to new server successfully.
In my old server, I do not need to do the following but for some reason to do with PLESK that I am using, I have to CHMOD 777 for my directory "files" and "files/tmp". I also have to CHMOD 777 for other directories for use by FCKEditor such as "Image", "Flash" and so on.
Can someone enlighten me on the security implication for using CHMOD 777?
Thanks!
Comments
Additional notes
I forgot to mention that if I do not CHMOD 777 for those directories, my file uploads and CSS aggregation do not work.
To be a little specific, I have discover that it has something to do with my User and Group.
SOLVED!
I have just RESOLVED my own problem! Thanks to help from some technical friends.
The problem is that PLESK, the control panel for my linux server is setting itself as my GROUP.
So the solution is to change the directories' GROUP ownership from "psacln" (plesk) to "apache" (web server).
I am not sure if the values would be similar for others but this is basically the idea behind the solution.
Unfortunately, you need to have root access and be able to use the command "chown" to change the ownership.
If you are those with basic webhosting solutions, then you probably won't be able to do this without the help of your hosting provider.
After I have changed the GROUP ownership, I can then CHMOD 775 those directories to reduce security risks.
(no title)
Yes, with 777 someone who got access to a user account on your machine might be able to write to those directories.
Now with 775 only someone using a php script (which writes as user apache) on your machine might be able to write there.
That sounds like the correct
That sounds like the correct solution, and it does take an admin to do it for you, so even telling you what to do would probably just be frustrating.
I choose to put my user account into the same group as the web server ASAP (when I can) so we can swap files.
A umask of 0002 (for the web daemon) also helps, creating files that are shared with the group by default.
Man it's frustrating finding myself installing on a web host that doesn't have that set up right!
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
What is the real vulnerability?
I don't think that other users on the server are a particularly high risk to your /files. Unless other users can ssh into the server, they should not be able to access (through http or ftp) anything but their own files.
Php is probably the biggest source of vulnerabilities in this context (running Drupal on a linux server). You don't want someone to be able to run code on the server that can do bad things, such as help somone access your database or create/read/modify files on the server.
AFAIK, Php should run as the apache user. The apache user should not have privs to write to the filesystem, other than the areas designated for it - it should have really limited privs. You need apache (and thus php) to be able to write to some areas of your directory so that you can provide some functionality (saving uploads, etc...) You don't want apache to be able to modify php files in your drupal install - that opens the door to a remote attacker uploading malicious code and then being able to run it. So you need to make everything other than what is strictly needed to be writeable to be read-only.
A remote attacker can upload php code to the files directory (or html editor subfolder) and run it if you don't prevent them from doing so. You can be relatively sure that the core modules do not allow that, and that's a good reason to try to limit the number of non-core modules you have on your drupal install.
Maybe someone with more in-depth knowledge of drupal's security can comment on that.
So, apache has to be able to write to the files either way. Whether they are 755 and owned by apache or 777 and owned by you, the risk is the same. That's the cost of providing that functionality. You just have to be sure that nothing else is writeable by apache.
I was confused at first,
I was confused at first, ..then saw that you make a damn good point.
The attack vector is from other folk on the machine ... who have as much control over the apache user as you do. So locking 'other' users out whilst letting 'apache' user in ... has no true gain!
So, FWIW, when you open up /files to apache-write, yo might as well be letting the world in :-/
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
(no title)
True, I recently posted a related story in this comment
http://drupal.org/node/162073#comment-258679
the moral of which (I think) is that a book on Unix file system can't tell you the whole story about web security.
In that case, I have all directories 755 and all files 644 without exception, and still apache can write *everywhere*, which it couldn't do before.
VPS with 1and1
For those searching and have a 1and1 VPS account with Plesk, this is what you need to do. After migrating my permisisons did not copy over and 777 seemed the only way for a while until I read this comment, thank you tengo!