0

I'm using the WP Smushit Pro plugin created by WPMU DEV. Their support won't go this far so I'm reaching out. I'm pretty sure it's my server that has the issue anyway.

When an Image is Smushed, the PHP function rename() runs and overwrites the original image.

Problem is:

Permissions are changed leaving the image inaccessible to online users

Previous permissions: rw-r--r-- (0644)
After modifed Perms : rw------- (0600)

UPDATE

The optimized (smushed) image is created as a .tmp file (rename()) in the same directory before being copy()'d to overwrite the existing file.

Image Optimization Workflow

  1. Send original image (imagename) to get smushed
  2. Image returns, store it as imagename.tmp file
  3. copy imagename.tmp file to imagename - the original file

Have you encountered this type of permissions modification before?
If so, what can be done to gracefully solve the problem?

Community
  • 1
  • 1
Damien Wilson
  • 315
  • 3
  • 9
  • Can you quote the part of the PHP documentation are you referring to? – tmt Apr 17 '15 at 10:21
  • Can you also state what **permissions** and **user/group ownership** the file has before and after the rename? – tmt Apr 17 '15 at 10:26
  • @cascaval thanks for your assistance. I made an incorrect statement. The documentation doesn't mention inheriting origin perms - I've updated the question. – Damien Wilson Apr 17 '15 at 10:36

1 Answers1

1

Please be aware of what it means to rename a file.

When the file remains on the same file system, a rename is not actually an operation on the file itself. It only modifies directories: the directory the file was in and the directory the file will be in. It does not affect the content or properties of the file itself, such as its access permissions and ownership. (A file's name is not a property of the file, but of a directory entry pointing to the file.)

For consistency, this also applies when a file is moved across file systems, even though in that case, underneath the covers, a new file must be made and its contents and properties most be copied over.

So you probably need to fix the default permissions used to create new files (the umask) that is in effect for the plugin.

reinierpost
  • 8,425
  • 1
  • 38
  • 70
  • Thanks for the great explanation! But I'm lost. How do I apply, and what is the best setting for a web umask? – Damien Wilson Apr 17 '15 at 10:57
  • One more thing, PHP docs say: _Attempts to rename oldname to newname, moving it between directories if necessary. If newname exists, **it will be overwritten**._ Each file already exists so an overwrite will take place - that will modify the contents right? – Damien Wilson Apr 17 '15 at 11:02
  • I have output the web user umask and it says `0002` - is that OK? FYI - I updated the question – Damien Wilson Apr 17 '15 at 11:18
  • If it will really be overwritten,, that would mean the contents are copied into the pre-existing destination file; in that case, I'd expect the permissions to stay what they were. – reinierpost Apr 17 '15 at 13:21
  • 0002 looks OK, so this may be a red herring. – reinierpost Apr 17 '15 at 13:21
  • confusing right :) thanks for your help so far! I've added the file opt. workflow to the question – Damien Wilson Apr 17 '15 at 13:47
  • I suppose by 'it will be rewritten' they mean: the old file will disappear and a the new one takes its place - within the directory, that is. The old file will probably just be `unlink()`ed from its directory, which will delete it as a side effect if no more links to it exist. – reinierpost Apr 20 '15 at 12:57
  • I've found the root cause of the problem: a (currently) unknown program is modifying the umask during script execution from 0002 to 63. I'll get to the bottom of it. Thank you for pointing me in the right direction! – Damien Wilson Apr 20 '15 at 14:06