Results 1 to 4 of 4
  1. #1

    Why does Apache show an index of wp-content/uploads?

    VPS, Centos 6.4, Apache 2.2.15.

    In getting WordPress up and running, setting the wp-content/uploads directory permissions to 777 was the only way I could find that allowed me to upload image files.

    When I point the browser to the directory, it comes up as an Apache result showing the directory contents and links to the contents.

    Is it because the directory is set to 777?

    I understand that having the directory at 777 is a "security risk" but what is the actual risk in this particular case? Could an attacker without access to the WP dashboard upload an executable file?

    Is there a way to stop apache from showing this result while keeping the permissions at 777?

    Might there be another way to get the WP file upload to work without going to 777?

    Thanks for your thoughts.

  2. #2
    Join Date
    Mar 2007
    So you have two questions here.

    1. Why is Apache showing a directory listing of all the files.
    2. How to properly setup permissions. (In other words, don't use 777).

    For the listings, this is actually a feature of Apache. If there is no "Index" file, such as index.html, index.php, or whatever you have set as acceptable index files, Apache will just list all the files in the directory.

    You can configure this on and off, just take a look at the documentation.

    Or if you want to post your Apache configuration files, we can help you out as well.

    Second, regarding 777. When you upload something from the Wordpress dashboard, Wordpress needs to be able to write that uploaded file into the uploads directory.

    Now, your linux box doesn't really care who/what Wordpress is. Because Wordpres is a PHP application, you need to make sure that whatever user is running the PHP process has access to write.

    In your case, I'm assuming you're using Apache with mod_php, meaning PHP is run by the same user as Apache. (Not the BEST idea, but no biggie).

    Go check your Wordpress files and folders and see who owns them. If it's not the same user as Apache is running under, Apache won't be able to write your uploaded files.

    This is why you had to set it to 777. 777 allows ANY user on your system to write and execute.

    If you only want your Apache user to write/execute the files, make sure Apache owns them. Then you can set more sane permissions on your files and directories. Like 755 on directories and 644 on files.

  3. #3

    Now I see what you're doing there, WordPress

    Thank you!

    When I point to the directory wp-content, one directory up from wp-content/uploads .... all I get is a blank page.

    But then I noticed that there is an index.php file in that directory:

    // Silence is golden.

    So I guess I could copy that file into wp-content/uploads and that would at least restrict the display of the files.

    As for permissions and users, here is (a shortened) ls -la of that directory:

    [[email protected] uploads]$ ls -la
    total 408
    drwxrwxrwx 2 root root 4096 Nov 24 19:27 .
    drwxr-xr-x 5 nobody 65534 4096 Nov 24 23:22 ..
    -rw-rw-rw- 1 apache apache 48091 Nov 24 19:27 cropped-attic_banner-1024x147.jpg
    -rw-rw-rw- 1 apache apache 8198 Nov 24 19:27 cropped-attic_banner-150x150.jpg

    But I see now that the file ownership thing is not lining up, as you suggested:

    [[email protected] wp-content]$ ls -la
    total 24
    drwxr-xr-x 5 nobody 65534 4096 Nov 24 23:22 .
    drwxr-xr-x 5 nobody 65534 4096 Nov 24 15:39 ..
    -rw-r--r-- 1 nobody 65534 28 Jan 8 2012 index.php
    drwxr-xr-x 4 nobody 65534 4096 Nov 24 23:48 plugins
    drwxr-xr-x 4 nobody 65534 4096 Oct 29 16:08 themes
    drwxrwxrwx 2 root root 4096 Nov 24 19:27 uploads

    Config file section:
    LoadModule auth_basic_module modules/
    LoadModule auth_digest_module modules/
    LoadModule authn_file_module modules/
    LoadModule authn_alias_module modules/
    LoadModule authn_anon_module modules/
    LoadModule authn_dbm_module modules/
    LoadModule authn_default_module modules/
    LoadModule authz_host_module modules/
    LoadModule authz_user_module modules/
    LoadModule authz_owner_module modules/
    LoadModule authz_groupfile_module modules/
    LoadModule authz_dbm_module modules/
    LoadModule authz_default_module modules/
    LoadModule ldap_module modules/
    LoadModule authnz_ldap_module modules/
    LoadModule include_module modules/
    LoadModule log_config_module modules/
    LoadModule logio_module modules/
    LoadModule env_module modules/
    LoadModule ext_filter_module modules/
    LoadModule mime_magic_module modules/
    LoadModule expires_module modules/
    LoadModule deflate_module modules/
    LoadModule headers_module modules/
    LoadModule usertrack_module modules/
    LoadModule setenvif_module modules/
    LoadModule mime_module modules/
    LoadModule dav_module modules/
    LoadModule status_module modules/
    LoadModule autoindex_module modules/
    LoadModule info_module modules/
    LoadModule dav_fs_module modules/
    LoadModule vhost_alias_module modules/
    LoadModule negotiation_module modules/
    LoadModule dir_module modules/
    LoadModule actions_module modules/
    LoadModule speling_module modules/
    LoadModule userdir_module modules/
    LoadModule alias_module modules/
    LoadModule substitute_module modules/
    LoadModule rewrite_module modules/
    LoadModule proxy_module modules/
    LoadModule proxy_balancer_module modules/
    LoadModule proxy_ftp_module modules/
    LoadModule proxy_http_module modules/
    LoadModule proxy_ajp_module modules/
    LoadModule proxy_connect_module modules/
    LoadModule cache_module modules/
    LoadModule suexec_module modules/
    LoadModule disk_cache_module modules/
    LoadModule cgi_module modules/
    LoadModule version_module modules/

    # The following modules are not loaded by default:
    #LoadModule asis_module modules/
    #LoadModule authn_dbd_module modules/
    #LoadModule cern_meta_module modules/
    #LoadModule cgid_module modules/
    #LoadModule dbd_module modules/
    #LoadModule dumpio_module modules/
    #LoadModule filter_module modules/
    #LoadModule ident_module modules/
    #LoadModule log_forensic_module modules/
    #LoadModule unique_id_module modules/

    So ... I could just change the user ownership of the files as well? Just change those to Apache, and I can back down the permissions?

    What about the .htaccess?

    drwxr-xr-x 5 nobody 65534 4096 Nov 24 15:39 .
    drwxr-xr-x 3 root root 4096 Nov 24 12:40 ..
    -rw-r--r-- 1 root root 201 Nov 24 13:46 .htaccess
    -rw-r--r-- 1 nobody 65534 418 Sep 24 20:18 index.php
    -rw-r--r-- 1 nobody 65534 19929 Jan 18 2013 license.txt
    -rw-r--r-- 1 nobody 65534 7128 Oct 23 16:08 readme.html

    Thank you!

  4. #4
    setting things to 777 is a security risk because there are no limits to what an attacker could do if he has access to the server. (for example through ssh) But if the attacker doesn't have access then the permissions don't really matter. So moral of the story: Make strong passwords on your ssh and you'll be fine

Similar Threads

  1. Help to use sub-domain for /wp-content/uploads/.
    By Slim Shaddy in forum Domain Names
    Replies: 1
    Last Post: 04-21-2013, 09:56 AM
  2. Best Hosting Type for Image and Content Uploads
    By OllieBarnett in forum Web Hosting
    Replies: 7
    Last Post: 11-10-2010, 12:29 PM
  3. Show ONly On Index in IPB
    By Syphon in forum Programming Discussion
    Replies: 1
    Last Post: 05-16-2006, 07:18 PM
  4. My Website Index.html does not show up!
    By jmp4306 in forum Hosting Software and Control Panels
    Replies: 13
    Last Post: 07-11-2004, 10:23 AM
  5. CGI Uploads: Perl, Apache, and Permissions
    By krcDeuce in forum Hosting Security and Technology
    Replies: 9
    Last Post: 07-22-2003, 03:25 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts