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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drewish’s picture

Status: Active » Postponed (maintainer needs more info)

not 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?

moscow-tyger’s picture

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

derhasi’s picture

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

derhasi’s picture

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

drewish’s picture

Status: Postponed (maintainer needs more info) » Active

do you experience similar problems with the core upload.module?

derhasi’s picture

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

Brian@brianpuccio.net’s picture

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

drewish’s picture

Version: 5.x-1.2 » 5.x-1.x-dev

marked http://drupal.org/node/170365 as a duplicate

drewish’s picture

derhasi, 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?

Brian@brianpuccio.net’s picture

Assigned: Unassigned » Brian@brianpuccio.net

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

Brian@brianpuccio.net’s picture

Was 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?

drewish’s picture

i'd say that we just need to document the solution.

Brian@brianpuccio.net’s picture

Status: Active » Needs review
FileSize
391 bytes
drewish’s picture

Status: Needs review » Fixed

committed to HEAD and DRUPAL-5

Anonymous’s picture

Status: Fixed » Closed (fixed)
Owen Barton’s picture

Assigned: Brian@brianpuccio.net » Unassigned
Status: Closed (fixed) » Needs review
FileSize
700 bytes

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

drewish’s picture

Version: 5.x-1.x-dev » 6.x-1.x-dev

unless the fix for this is 5.x specific it'd need to be committed to HEAD and then backported.

Owen Barton’s picture

FileSize
725 bytes

Here you go :)

drewish’s picture

Version: 6.x-1.x-dev » 5.x-2.x-dev
Status: Needs review » Patch (to be ported)

thanks, committed to HEAD.

drewish’s picture

Version: 5.x-2.x-dev » 5.x-1.x-dev
FileSize
809 bytes

committed the attached to the 5.x-2.x branch.

drewish’s picture

Status: Patch (to be ported) » Fixed

and committed the patch in #13 to DRUPAL-5... whoops, i realize i should have given Brian credit too...

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.