Advanced problem – image upload

Actually you should only have to chmod 777 the 1st time you upload. After that chmod 755 is supposed to work.
Also, if you’re using FF and dragging and dropping the images, it’s a known FF bug. You’ll have to click on the image and “send to editor”.

So they say, samboll. I’ve had exactly the same situation as louse101 – the uploads folder requires setting at 777 to allow uploads, forever apparently. I have one client who insists on doing things this way, and she’s signed a contract amendment that if her blog/server (not on MY space thankfully!) gets hacked, SHE is at fault, not I.

I dunno…. all the installs I’ve done work “correctly” too – until you want to use the uploads function.

And it’s NOT server specific. This is an entirely new host, different server, etc. – and it’s still not possible to change the uploads folder back to 755 and make it usable.

Would changing your web server to run suexec’d be an option?

A few sites I run were just hacked using the (wide open) /uploads/ folder (CHMOD 777).

You can see if your site(s) have been hacked by using this very useful site. To see if your own domain (or IP) was hacked, put your own IP up in the URL at the end.

I use Image Manager for image uploading and right there on the options page, Soderlind tells me something I should have read (and acted on) long ago.

Base image directory

The base image directory must be world writable i.e.: chmod 777
Base image URL

The URL to the base image directory, the web browser needs to be able to see it.

Note that the directory can be protected via .htaccess on apache or directory permissions on IIS, check your web server documentation for further information on directory protection. If this directory has to be publicly accessible, remove scripting capabilities for this directory (i.e. disable PHP, Perl, CGI). We only want to store images in this directory and its subdirectories.

On apache you can create the following .htaccess file in your base image directory:

<Files ^(*.jpeg|*.jpg|*.png|*.gif)>
		   order deny allow
		   deny from all
		</Files>

So at least then only images could be (hackingly) uploaded to your folder. I’m going to give it a shot.

Best,

– Bradley

The key here is group privileges. The short answer is to use 770 privileges on wp-content and wp-content/uploads, and it will work securely, without any .htaccess mods.

Here is a longer answer for interested Linux users.

WP docs state “any file that needs write access from WordPress should be group-owned by the user account used by the webserver”. This is pretty terse – it gives you a big clue (but not all the details you need to understand WP file security on Linux).

Here is a fuller explanation.

If you know what 777, 755 etc mean, skip to next para. Octal privileges are a codified way of representing file access privileges: read=4, write=2, execute=1. So read+write+execute is 7, read+execute is 5, read+write is 6, read only is 4, no permissions is 0. You can assign different privileges to the OWNER of the file or directory, those in the same GROUP as the file or directory, and to WORLD (everyone). That is three groups of three. A directory with all privileges available to owner, group and world is drwxrwxrwx, or 777. A file with read+write+execute privileges for the owner and read+execute privs for group and world is -rwxr-xr-x, or 755 (the first character is d for directory or – for a file). Ok, now we are clear on octal privileges.

Now for WordPress uploads, lets assume your Linux user is “boris”, WordPress runs under the webserver user “apache” and you want to upload into wp-content/uploads.

The wp-content/uploads directory needs privileges set to 770 (as does wp-content itself):
drwxrwx— uploads boris apache 4096 May 19 07:17

770 means boris has read(4)+write(2)+execute(1)=7 privs on the directory, apache has r+w+x privs on the directory, and world (public) has no privs on the directory.

When you are using the image uploader (or any other time via a browser), WordPress is running under apache (the webserver). The directory is in the apache group, and the directory has group permissions of 7 – r+w+x.
So WordPress – via apache – has write privileges to the directory it needs to upload

755 won’t work. When you use 755, this is only r+x (4+1) for the group. No write privilege for apache, therefore no write privilege for WordPress and an error results.

Execute permission on a directory means the contents of the directory can be listed. You can’t create a file in a directory without also having execute privileges (this protects you from creating a file that you can’t verify by listing), so the webserver user (apache) needs both write and execute privileges for WordPress to be able to upload.

Technically files such as as jpg’s only need 660 permission (read + write). Execute permission is irrelevant for a file like a jpg (it doesn’t have an executable form).

In summary, use 770 privileges for wp-content and wp-content/uploads if you want to be able to upload files via WordPress (and WordPress plugins, as they will also be running under the webserver). If you are connecting via ftp using your own user, you will have owner privs, usually r+w+x. World privileges are not required (or desirable). Using 770 for wp-content and uploads, you won’t need any special htaccess directives either.

These principles apply all across WordPress directories e.g. themes updateable etc.