I am starting this off as a new thread and not as a comment to http://drupal.org/comment/reply/32996 as it is too long. I am having lots of difficulties using the image module.
1.) files and files/images directories were created for me by drupal, yet files is set to 777 while images is set to 740 and when I try to change the permissions to 777 through FileZilla, I get a permission denied message.
2.) When I create an image node (create content>>image), I am able to see the enhanced 'attachements block' in the node creation form listing the following:
Delete List Url Size
The url of the images are as follows:
system/files?file=images/bg_1.png for preview
system/files?file=images/bg_0.png for thumbnail
system/files?file=images/bg.png149 bytes
The image doesn't actually show up in the node, but clicking on submit says the node was successfully added etc. When I go to files/images in my drupal install, there is nothing in it, nor any tmp folder.
I don't get any error messages in the admin section relating to the image module. And, if drupal created the files and images directories, how come the image path references 'system', which I assume is the web server? Also, I have clean urls turned on but these urls are different.
If I do a php()info on the site where drupal is installed, the location of upload_tmp_dir is given as /usr/temp
User group is shown as nobody(65534)/998
What am I doing wrong?
Comments
Problem solved
As I suspected, it had to do with the 'images' directory being set to 740. After I enabled the Owner/Group setting in Filezilla, I realised that 'images' was set to 'nobody/users'.
I sent a request to my host asking them to set 777 for 'images'. After that, the images uploaded fine (temp folder was automatically created and the images also appeared) and I haven't had a problem.
However, my host also cautioned that anyone could now access those directories and suggested running php under cgiwrap. To quote:
My question: Is it absolutely essential to run drupal under php-cgiwrap or does Drupal take care of the security despite the folders being set to 777?
Same problem here
I ran into the same problem last night. I noticed any directory I created in the files directory was 755 so I set the images directory to 755 and it worked. I didn't do anything with the image permissions. Sorry I can't answer your question on cgiwrap.
Tim
May be it is the way my web
May be it is the way my web host is configured, but I have never been able to change the permissions. Glad to know that 755 also works in some hosting setups.
Security
If you have the option of running PHP as your userID take it. It shouldn't affect anything (famous last words), and would let you keep all your files with no permissions for world. There are a couple of solutions for running PHP as your ID (eg suphp). I'm not personally familiar with them though - I admin my own dedicated server.
Although running stuff as yourself is more secure overall there is one small security aspect to be aware of though, but it is one you have more control over.
When the server runs as someone else (eg 'nobody'), you can give the user 'nobody' (through world permissions) read only access to your PHP files. That gives you some protection against someone exploiting a site on the server to get at your files. This is no protection against someone gaining root on the server though (eg by breaking the ISPs security rather than just one sites security). But you do need these nasty holes (eg world writable permissions) in places where you want the webserver to be able to write to. And these lowered permissions leave your uploaded files vulnerable to all the other users on the server, or anyone that has broken into someone elses site.
When running as your own ID, you can now lock everyone else but your ID (and root of course) out completely. But if someone breaks your own site (eg with a Drupal vulnerability), all your stuff (not just the uploads anymore) is able to be tampered with. Of course this is generally a better situation because you are in control of your security rather than hoping everyone else on the server has good security or good intentions.
When running as 777, Drupal can't protect you. All anyone else on the server has to do is figure out your diectory path, and they could do just about what ever they liked with your files. If you look through the PHP docs you will see lots of functions for manipulating filesystems - you could see how easy it would be to upload PHP scripts that do bad things to other users world writable files.
A point (you've probably now figured this out) about unix filesystem permissions. You can only change the permissions of files and directories you own. Stuff created by the webserver will usually (ie when not using something like php-cgiwrap) be owned by someone else. Of course there is a workaround - you could upload PHP scripts to change these permissions and they will run as the owner of the files in question.
I don't know if you've seen the pages here yet:
http://drupal.org/node/34022
--
Anton
Great explanation, Anton. As
Great explanation, Anton. As always, many many thanks. I really feel your explanations here and elsewhere have helped me understand drupal better.
I forgot one more advantage
of running as your own uid. You can set the permissions on your settings.php (you know the one with your database connection string) to something like 600.
Otherwise, if it is world readable so the webserver can read it, then there is a chance someone else could read your database password too.
--
Anton
Great. Anything that adds
Great. Anything that adds even a wee bit more security is worth trying. Thank you for the tip.
how come the image path
Oh yeah - that would probably be the Drupal system module. With private downloads the system module seems to be what allows access to the files, then serves them up. With public downloads the user just requests them directly from a web accessible directory on the web server - no PHP involved at all, just the web server.
--
Anton
You are absolutely right. I
You are absolutely right. I set my downloads to 'private'.