Make WordPress Core

Opened 15 years ago

Closed 14 years ago

#4151 closed defect (bug) (fixed)

uploaded image thumbnails permissions incorrect

Reported by: DD32 Owned by:
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.1
Component: Administration Keywords: thumbnails, has-patch
Focuses: Cc:

Description

I've just realised i've got an issue regarding the creation of thumbnails of uploaded images.

-rw-r--r--  1 theonly theonly 51894 Apr 15 20:40 oct_2005.png
-rw-------  1 theonly theonly  9156 Apr 15 20:40 oct_2005.thumbnail.png

PHP is running under suPHP, the thumbnail in this example(live data) will be returning 403.

The fullsize image is being chmod'd correctly (i believe on line 1993 of admin-functions.php).

The thumbnail file however isnt getting the same action, its being left as is.
Attached is a patch which uses the same chmod code from the upload function to modify the permissions of the thumbnail thats created.

Heres the result after the patch applied:

-rw-r--r--  1 theonly theonly 217891 Apr 15 20:58 active_threads.png
-rw-r--r--  1 theonly theonly   3104 Apr 15 20:58 active_threads.thumbnail.png

Attachments (2)

4151.thumbnail.creation.patch (493 bytes) - added by DD32 15 years ago.
chmod patch for thumbnail creation
4151b.thumbnail.creation.patch (704 bytes) - added by DD32 15 years ago.
Patch thats uptodate with SVN-Trunk after admin re-organisation

Download all attachments as: .zip

Change History (7)

@DD32
15 years ago

chmod patch for thumbnail creation

#1 @DD32
15 years ago

  • Cc DD32 added; dd32 removed
  • Keywords has-patch added

#2 @rob1n
15 years ago

The thumbnails are created by the server, and thus will be owned by the server, and thus the server can access them.

#3 @DD32
15 years ago

The uploaded files are created by the server too.
I think there may be something wrong with the servers umask in my case, however, its obvious that WP has changed the default permissions on the uplaoded file, But not applied the same attention to the thumbnail it then creates

The problem is that the file thats created is ONLY readable by the username which created it.
In a normal world where Apache is running without suPHP, the PHP process is often owned by the user 'nobody', The created files will be owned by nobody, So the thumbnails are created by the server and written to the disk with the username of nobody; When Apache comes to serve up the image thumbnail, Since its running under the same username as the file was created as, it can read the file, and serve it with no problems.

Now, We introduce suPHP into the mix.
the PHP Process now is running under the username of the user, So its running as "theonly", It creates files with the owner/group as "theonly". That seems right, Right?
However, When the files are created, they're set read/write for THAT user("theonly")
Now, Apache comes along under the username "nobody" to serve this image up, It tries to access the file, Hang on, permissions are set to -rw-------, Only the OWNER of the file has read-access to it!, apache is running as nobody, Apache CANT open the file to serve it. 403 sent out.
For Apache to serve the file while running under a different username than the file, the file needs its permissions set to World Readable: -rw-r--r--
Now we might as well make it group-readable while we're at it(thus the other group readable mark in there)

Thats why the uploaded file is chmoded in the first place, For the cases where PHP is being run under a different username than what the created file will be served under..

Hopefully i've managed to get this out right without too much confusion :S

#4 @rob1n
15 years ago

  • Milestone changed from 2.2 to 2.3

@DD32
15 years ago

Patch thats uptodate with SVN-Trunk after admin re-organisation

#5 @westi
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [6309]) Refactor of wp-admin/includes/image.php. Fixes #5312, #4151, #4709, #5304 props DD32.

Note: See TracTickets for help on using tickets.