RTK

@rsgrone – Windows Server 2008 R2 Standard Edition

Nobody has actually listed the extentions that they disabled…

@rtk – are you able to write to the Plugins folder now? That is, have you attempted to place or replace/update plugins to that folder yet? I was given a denied error even login as administrator…

Had to give the folder write privileges to all again to correct the error…

I did not have to give write permissions to the folder, however I do all of my updates manually as opposed to automatically since FTP is blocked at the firewall level where I have my server hosted.

Unfortunately none of the solutions described above that involve changing cPanel settings or changing PHP extensions to run under PHP 5.x only help me. I host a Windows Server 2008 R2 server using the latest PHP 5 myself, not through a hosting company, so unless the new WordPress doesn’t like some of the default PHP extensions enabled in my PHP.ini (HIHGLY doubtful seeing as how I’m sure they QA their changes against a fairly defualt PHP installation), then those suggestions don’t resolve this issue.

The only true workaround I’ve found is to do as I described earlier and give the IUSR user write permissions on my wp-content directory. This is the only solution (and I hesitate to even call it a solution) I’ve found for my setup.

It just depends on how you have your server configured. By default IIS 7 has anonymous authentication enabled with the user account IUSR as the identity being used. If your server is configured differently, you may not be using IUSR as the default anonymous identity, in which case it would not matter if you granted rights to IUSR.

Since you’re running IIS 6 (Windows Server 2003), your default anonymous authentication account, and thus the account that PHP scripts would be executing under, is IUSR_computername, where <computername> is the name of your machine. This IUSR_computername user is a member of the Users group, so that is probably why when you grant more privileges to the Users group you’re able to upload. Try only adding extra permissions to the IUSR_computername user and see if that works for you.

Correct, that seems to be the case for me. Since IUSR is the one actually being used for access requests to the file system by PHP based on my server’s configuration, as long as I grant the permissions I outlined above to my server’s WordPress installation, everything seems to work like it did before 3.3.

Hmm, yeah this definitely seems like some sort of weird permission issue with Windows-based setups that are running PHP via FastCGI I guess. For me, I ended up doing this get it working:

1) Granted IUSR Modify permission on the entire wp-content directory, allowing permissions to propagate down to its children
2) Broke inheritance and copied parent permissions to the wp-content/plugins folder, removing inherited IUSR permissions in the process
3) Broke inheritance and copied parent permissions to the wp-content/themes directory, removing inherited IUSR permissions in the process

So essentially what I’m left with is IUSR having write access to the wp-content root directory, the wp-content/uploads directory and subfolders, and that is all. The IUSR user cannot write to my plugins or themes directories, which is what I was aiming for.

Guess that works for now, but I’m still interested to know why the PHP user process seems to need write access to the entire wp-content directory when running WordPress 3.3. Maybe the code that was added for uploading in 3.3 makes use of different calls or checks and somwhere along the line fails if it can’t write to that directory for some reason?

I set this up a while ago, so I’m trying to recall…I think I manually created the uploads folder and granted permissions to it when I installed WordPress.

The weirdest part is exactly what you said though, if I grant the IUSR user explicit Modify permissions on the wp-content folder rather than just on the wp-content/uploads folder where it current has Modify permissions, this error goes away and I’m able to upload featured images again. Even though WordPress states that the wp-content folder is meant to be writeable by the public, I really don’t trust giving the public internet user write permissions to my theme and plugin directories. Not sure why the new code for 3.3 seems to require that the parent wp-content directory is writable rather than just the wp-content/uploads directory. Any info from the WordPress gurus on this? Thanks!

If you grant Modify access to the Users group on the entire /wp-content folder, you’re granting read/write/delete access to any low-privileged authenticated user account on the system. Members of the Users group cannot, by default, write to the inetpub\wwwroot directory being hosted by a Windows IIS server. So for example, if I were running the MySQL service as a standard user and an attacker exploited a vulnerability in the software that allowed them to gain control of that process, they could potentially write to my blog content folders now that I’ve granted Modify permissions to the Users group. They could host malicious contnet, they could overwrite my theme files with their own, etc. Generally speaking you will only want to give Read access to processes that serve internet content anonymously, with exceptions being made for special folders like the wp-content/uploads folder when needed.

You’re right though, the main point at hand is that we had the ability to upload prior to 3.3 and now for whatever reason, something has changed in the code or function calls that doesn’t seem to allow us to do that anymore.

Unfortunately, giving the Users group modify permissions on the entire wp-content folder is not an acceptable workaround unless you’re willing to compromise the security of your blog. The worker process for your web server should not have modify permission on any directory except where absolutely necessary. If you grant this permission, you open yourself up to people potentially being able to alter your content, deface your blog or host malicious files if they find vulnerabilies in WordPress or any plugin you’re using. Granting full permission to the Everyone group (as a test) on the /wp-content/uploads folder should be more than enough for WordPress to upload files to it. Since this test failed, and since I’ve never had any issues prior to upgrading to 3.3, I can only assume something was changed in the uploader code that is now having a negative impact on Windows/IIS based WordPress installations.

Still looking for a solution, but haven’t found one yet.

How does WordPress change permissions when it is installed? Doing the manual installation, I just copy files from one directory to another…there is no installer or anything like that which would modify directory permissions. Also, since I checked the permissions on both of the upload folders in question, I’m not convinced that the web server and PHP processes do not have appropriate access to the resources they need.

@madvibes – Nope, I still have not been able to get it working. I’ve tried disabling all of my plugins and still have the same error. The only thing I have not tried is applying the standard Twenty Eleven theme to see if it could be a theme incompatability. Beyond that, I don’t know where to go from there.

Anyone else have any trouble with this? Or any other suggestions?

Thanks!

@keesiemeijer – I performed a manual update just like I normally do for all releases. I was updating from the latest 3.2.x version. I triple checked file permissions to verify that they were correct, and as I said before I haven’t changed them since I setup the blog.

@ipstenu – like madvibes, I also have plenty of files in my wp-content/uploads/2011/12 folder, and file uploading was working fine the day before I performed the upgrade to 3.3.

I fired up Procmon to take a look at what might be happening when I do a file upload and I’m seeing some references to a possible buffer overflow:

Procmon Screen Capture

That is what Procmon shows while I’m trying to upload a featured image. This is after I give full permissions to the Everyone user on both the PHP temp folder and the /wp-content/uploads folder.

I’ve double checked the php.ini file to ensure larger files are allowed to be uploaded, and I have upload_max_filesize = 2M. I’ve also checked the web.config that IIS is using and it has maxRequestLength configured to 4096 (4 MB). The file I’m uploading is somewhere in the 70 KB range, so I know that’s not the issue.

I’ve also tried the standard file upload as opposed to the new fancy upload and I get the same result.

Any help is appreciated! I have to think it’s a problem with the new code since nothing has changed on my end, but I guess that is yet to be determined.

Thanks!