I am using the basic image.module. File system has download method set to "public"
The node appears to be created correctly, and the derived images are generated, but they don't have the right file permissions.
:~/www.example.com/files/images
ls -l HopeBay*
-rw-rw-r-- 1 example users 707489 2007-06-20 20:57 HopeBay.9181.jpg
-rw------- 1 example users 282286 2007-06-20 20:57 HopeBay.9181.preview.jpg
-rw------- 1 example users 8806 2007-06-20 20:57 HopeBay.9181.thumbnail.jpg
The guts of image.module uses file_copy,which in turn uses chmod to set 0644 , but this appears to be ignored.
Any suggestions on where this could be being over-ridden?
Comment | File | Size | Author |
---|---|---|---|
#20 | image_153526.patch | 809 bytes | drewish |
#18 | image_chmod_6.x_0.patch | 725 bytes | Owen Barton |
#16 | image_chmod_0.patch | 700 bytes | Owen Barton |
#13 | suphp_doc_image_module.diff | 391 bytes | Brian@brianpuccio.net |
Comments
Comment #1
drewish CreditAttribution: drewish commentednot sure, perhaps it is because the derivatives are created in the temp directory and then moved there? are the image temp directory's permissions different than the image directory?
Comment #2
moscow-tyger CreditAttribution: moscow-tyger commentedThe images and temp directory both have the same permissions
images$ ls -ld temp
drwxr-xr-x 2 example users 4096 2007-06-21 03:00 temp
images$ ls -ld
drwxr-xr-x 4 example users 4096 2007-06-20 20:57 .
Comment #3
derhasi CreditAttribution: derhasi commentedI have the same problem (thumbnail, preview chmod 600). But when uploading the same image again as a second new node, so Drupal has to rename it (attach _0), thumbnail-images are shown (thumbnail, preview chmod 644). Original is allways chmod 664.
Comment #4
derhasi CreditAttribution: derhasi commentedI still did not find any solution. It seems to be some error in _image_insert() to force this problem. But I can't account any line.
Could anyone of you please look at it and help me?
With this error, Image is useless for me :( But I really need it.
Comment #5
drewish CreditAttribution: drewish commenteddo you experience similar problems with the core upload.module?
Comment #6
derhasi CreditAttribution: derhasi commentedUpload module works fine.
The orginal image is saved the right way, only derived images (like thumbnail and preview) are set to chmod 600 (or not set to 644?)
Also when image.module has to rename the images, cause the filename exists allready for another image, there aren't any problems. There all images are shown the right way (and chmod is set to 644).
Comment #7
Brian@brianpuccio.net CreditAttribution: Brian@brianpuccio.net commentedI can confirm that I have the same issue and am running the latest of image.module (because I wanted the fix for not generating the custom size images (i.e., medium and thumbnail) when uploading an image not as large as the medium image). I use the imagemagick toolkit, if it matters.
Comment #8
drewish CreditAttribution: drewish commentedmarked http://drupal.org/node/170365 as a duplicate
Comment #9
drewish CreditAttribution: drewish commentedderhasi, could you try setting a maximum image size for the upload module (so it resizes images) and let me know if it still works correctly?
Comment #10
Brian@brianpuccio.net CreditAttribution: Brian@brianpuccio.net commentedDoes the original poster run suPHP? I do. And WordPress has the same problems where the thumbnails generated have the wrong permissions for suPHP users.
http://trac.wordpress.org/ticket/4151
I'll try making a similar change to image.module tonight to see if that fixes the issue.
Comment #11
Brian@brianpuccio.net CreditAttribution: Brian@brianpuccio.net commentedWas doing some more digging, this is indeed a suphp issue. Previous issue with uploaded images and permissions. I adjusted the suphp config and the issue resolved itself.
Drewwish, since this is your module, do you still want to pursue a patch or just recommend that the umask be modified?
Comment #12
drewish CreditAttribution: drewish commentedi'd say that we just need to document the solution.
Comment #13
Brian@brianpuccio.net CreditAttribution: Brian@brianpuccio.net commentedComment #14
drewish CreditAttribution: drewish commentedcommitted to HEAD and DRUPAL-5
Comment #15
(not verified) CreditAttribution: commentedComment #16
Owen Barton CreditAttribution: Owen Barton commentedStill having this problem - the simplest workaround for this is to simply chmod server generated files to a more open mask.
This is exactly what Drupal core does in several places (see color.module, for example in http://drupal.org/node/119196) - this is perhaps suboptimal security wise, but until there is a standard 'fix_file_perms' function in core it's what we have.
Here is a patch that does exactly what color module does with image module generated files. The patch is for 5.x-1.x, but would be trivial to apply to 5.x-2.x.
Comment #17
drewish CreditAttribution: drewish commentedunless the fix for this is 5.x specific it'd need to be committed to HEAD and then backported.
Comment #18
Owen Barton CreditAttribution: Owen Barton commentedHere you go :)
Comment #19
drewish CreditAttribution: drewish commentedthanks, committed to HEAD.
Comment #20
drewish CreditAttribution: drewish commentedcommitted the attached to the 5.x-2.x branch.
Comment #21
drewish CreditAttribution: drewish commentedand committed the patch in #13 to DRUPAL-5... whoops, i realize i should have given Brian credit too...
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.