File Upload Error After Upgrading to 3.3

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.

Since the uploads folder does not exist on a fresh WP install, it seems logical for the system (WP) to ask for write permission on the wp-content folder. How else is it possible to create this folder? If memory serves, I did actually got such a message when I tried to upload a file on a fresh install. The system was not able to create the upload folder because of low priviledges over the wp-content folder.

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!

I used to play with the permissions of the IUSR in the past, because that was what I was doind in the old days, in simple ASP web apps.

In WP and other similar apps, PHP is the one that actually writes into these folders and only setting up the users account the way I described does the job. Giving write/modify to the IUSR doesn’t solve the problem.

Now, back to the issue… I was as well creating the uploads folder namually and setting it up the way required – and that was all – no issues!

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 was too lazy (or run non critical sites) to think of these extra steps #2 and #3 you mentioned. That;s great!

So, you say that Users is not required to get involved because IUSR can handle the entire job, right?

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.

It’s not just a Windows issue. I’m having the same issue with a Unix server and, having just spent the last week eradicating a malware virus from our server of 40 sites, I’m in no hurry to be granting any type of global write permissions for any reason.

The upload worked fine for two images and then stopped. That it is working in some cases and not others leads me to believe it is not a permissions issue, else how would I have been able to get the first two images imported?

BTW, working with IUSR instead of the Users account doesn’t work for me.

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.

Regarding the Windows Server issues (to which I rolled back my installation as it is not working either) it depends on whether you are using the Windows “Web Server” or the full blown release of the server. That is, a regular Windows server works with additional account privileges based on Active directory rights and the Web Server addition does not.

Hope that makes sense, I am very ill at the moment and not thinking clearly but, granting privileges as you stated above, “modify” instead of write leaves your files wide open to malicious attack…

I am guessing it has something to do with the code since; I have never had this issue through the 3.x.x process…

I opened a new thread hoping for an answer… I have a dedicated serve so; I am not fighting with the hosting company regarding rights, privileges, etc…

I am using GoDaddy as my host on a Unix server. All of my issues were resolved by disabling four PHP extensions.

Launch your hosting account, go to Settings > File Extensions Management and there are four PHP extensions (that were at the bottom of my list). I had to edit each one and change them from running under fastPHP 4.x or 5.X to running under just PHP 4.X or 5.X.

Hope this is helpful to someone else.

I was warned that some WordPress plug-ins require these extensions, but until I come across one that does, I’m simply happy that all 40 of my client blogs are up and running.

Any idea what the four extensions were?

I am not on godaddy but would like a look see into the issue…

Is the “Drag and Drop” feature appearing now as well? I have attempted to use the default WP theme, and had to make some rather unusual permissions changes however, that did not fix the drag and drop issue (which is not working regardless of the upload issue)…

Thanks

@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…

Everything is back to working. My permissions, as I suspected, were never the issue. My images uploaded some, but not all, times. A permission issue would have prevented them all times. Additionally, I had one out of 40 sites that worked perfectly. A permissions issue, I felt, would have affected all sites since they are on the same server — all which were upgraded at the same time. I also duplicated the one working site and then restored the database from a backup of the site I was replacing…also to no avail. The four extensions are for fastPHP 4.x and fastPHP 5.x.