WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#12070 closed defect (bug) (invalid)

Uploading images to wordpress running on IIS 7 Win 2008 results in bad permissions

Reported by: cgoudie Owned by:
Milestone: Priority: high
Severity: major Version: 2.9.1
Component: Upload Keywords:
Focuses: Cc:

Description

I have a clean install of 2008 server (not r2). I used the web platform installer to install wordpress into wwwroot.

However, when I add an image to a post, attach a PDF, or whatnot, the security permissions on the file in the upload directory are very strange. They aren't sufficient for iis to read those files (using the default application pool).

Additionally, the permissions on those files are substantially different than the permissions those files are supposed to inherit from the parent uploads folder. They are missing most of the groups, the IIS_IUSRS group gets "special permissions" instead of read or what it was previously set to.

I also tried adding NETWORK SERVICE to the upload folder permissions, and had it propagate down to the children, and that permission is also stripped from uploaded files.

Also of note, the subfolders for year and month do get the correct permissions.

Files created through plugin downloads or editing through wordpress do not have this problem.

Any attempt in windows to edit the permissions on those files immediately update the files with the proper permissions. Also, if I create a file in that directory from windows, it obtains the permissions from the parent.

This is a fairly direct install of the OS, wordpress through the web platform installer. I've added some plugins and I'm using the Atahuapla theme, but I dont suspect anything I'm doing would be affecting the permissions on these files.

There isn't anything of interest in my php error log after finishing an upload and attempting to display it.

Thanks for the help!

Change History (9)

comment:1 cgoudie4 years ago

As a note, if you change your application pool to run as LocalSystem instead of NetworkService you'll have enough permission to read these files (although the permissions are not being set correctly)

If your looking at this bug because you're having this problem, this may be a workaround for you.

comment:2 miqrogroove4 years ago

Off the top of my head, it sounds like the permissions are set wrong on your PHP temp directory. Please close as invalid if you get that figured out :)

comment:3 ruslany4 years ago

Which PHP version do you have? I know that in PHP 5.3.0 there was a bug in fastcgi impersonation that might cause problems like this. If you have that version then try upgrading to 5.3.1.

comment:4 dd324 years ago

WordPress (And PHP In general AFAIK) cannot modify the Windows group permissions upon file creation..

However, You should be able to play with the IIS settings to create the files properly.

Also, Did you use the IIS WordPress Web App installer? http://codex.wordpress.org/Localized_Package_for_Windows_Web_App_Gallery

At this point, i'm thinking this is purely in the area of server configuration.

comment:5 cgoudie4 years ago

miqrogroove has it. When it moves the file from the temporary dir to the uploads dir, the permissions don't get updated.

I had to change the permissions on my temporary directory to include some read/write permissions for the IIS users group.

dd32: I did use the IIS WordPress Web App Installer through the web platform installer.

It seems to me that when running on Windows, WP should copy the file into place and delete the file in the temporary directory, or WP could update the permissions after the upload is complete

Alternatively this could be looked at as a bug with the installer where it doesn't either set the permissions on the temporary directory, or it doesn't change the php uploads directory to be something in the uploads dir itself.

Anyone who installs WP for IIS on 2008 server will hit this problem.

comment:6 miqrogroove4 years ago

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

Glad you got it working. See the PHP installation instructions for future reference, and the uploaded file handler at http://www.php.net/move_uploaded_file

comment:7 cgoudie4 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

If I had been the one to install php, and manually install WP on this box, I'd agree, this bug should be closed.

The installation of PHP was handled by the one click web platform installer, therefore from a user experience perspective, I'd expect it the installer to configure the php temporary directory as needed. It does so for everything else.

If I'm installing WordPress for the first time on a windows server, I may not even know what PHP is, that it has temporary directory permission issues during for file uploads, or that I have to make any sort of changes to it on my own. My expectation is simply for the WP features to work, and when they don't I think it's a bug with WP.

I still think the copy solution would be more robust, as it would inherit the proper permissions when the file is created, but in the end if the WP installer added the appropriate permission to the temporary dir, or moved the temporary dir inside the wp directory (so as to obtain the permissions that way) I wouldn't have experienced any problems.

It does sound like at the minimum the component for this bug should be changed, but I cannot see a component specifically related to the web platform installer.

comment:8 dd324 years ago

It does sound like at the minimum the component for this bug should be changed, but I cannot see a component specifically related to the web platform installer.

I think this is the first time its ever been raised on Trac.

Personally i believe this is a problem with the PHP installer, It should create the PHP directories and set the security on the folders correctly. Its not the job of WordPress to fix PHP's potential bad configurations.

comment:9 nacin4 years ago

  • Milestone Unassigned deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

Re-open with feedback.

Note: See TracTickets for help on using tickets.