Directories Set to 777 are Safe/Unsafe?

Posted November 9th, 2006 by Mike Cherim

777 - Safe or Unsafe? I will first say this as a disclaimer: I’m not a hacker, cracker, or a server security expert! This post is more of a question than an answer. Okay, now that that’s said I can get on with this short article. To the best of my knowledge, and after doing some research on the subject, and reading eighteen million conflicting versions of this information, I must tell you that manually setting directory permissions to 777 is not safe! Or at least I don’t think it is? I’m pretty sure if you set directories/folders on your server to 777 you can be cracked and probably will be, eventually — unless said directories were created with a server side scripting language thus taking ownership away from “Apache,” “Nobody,” or whatever the common default owner name on your server is.

Lots of top-shelf applications instruct users to set directories or folders CHMOD permissions to 777 — as in read-write-execute (-rwx-rwx-rwx-) for owner, group, and everyone, respectively — to allow functions such as file uploading. But this seems to be unsafe advice as they are telling users to do this via the server or via FTP thus not giving ownership over to the application itself. I feel it’s better to give ownership to the application (assuming the application is inherently secure) so as to allow the application access without providing a broader level of access. It seems they should provide a function to make a directory with the application using, for example, the PHP function mkdir(). That way the permissions can be reverted back to 755 which is safe. But this function can be tricky as the server side language must be allowed to do this in the first place.

As it relates to work on a web application I’ve been involved with for quite some time, I have researched this high and low. I’ve read accounts where one says it’s safe, then another will come along with alleged authority and say it’s not, only to be overridden by someone else boasting even greater authority on the subject to reclaim its safe use, only to be overridden by yet another — on and on it seems to go. The common thread I’ve found is that nobody seems to agree. This leaves me with questions, not answers, and I must rely on my own knowledge of it, which is to say it’s not safe, even on a dedicated server with all the proper security blocks in place.

Going out to find the answers yielded none, thus I hoping the answers will come to me. What’s your take on the subject? Are folders set to 777 safe? I say no, but I may be wrong. What’s the real deal?

16 Responses to: “Directories Set to 777 are Safe/Unsafe?”

  1. Dan responds:
    Posted: November 10th, 2006 at 4:42 am

    It’s a defence in depth thing IMHO. My understanding is that folders with permissions set to 777 are not at risk from your general site users, or from script-kiddies. For anyone to take advantage of those permissions they would need access to your server and its filesystem. That could be through a vulnerability in software (e.g. the vulnerability exploited in awstats 6.2 last year) or by direct access via ssh or telnet.

    If they have the ability to do that then either you have much bigger security problems to worry about (weak or compromised passwords, poorly configured shared server, etc) or they know enough for restrictive file and folder permissions to be less of a barrier to them.

    But that doesn’t mean it’s good practice to ignore file permissions. Set permissions to be as restrictive as possible without preventing your site functioning, and keep up to date on exploits and vulnerabilities that might effect your third party packages by subscribing to the SecurityFocus or F-Secure bulletins.

  2. Robert Wellock responds:
    Posted: November 10th, 2006 at 8:25 am

    It is not something I would recommend for a live web server. About the only time would be during automated installation ‘Everybody can do everything to this file’ is rarely a sensible idea, and once installed they should be CHMOD moved down to something more secure.

  3. Adam responds:
    Posted: November 10th, 2006 at 9:31 am

    Agreed. Not safe. Couple months ago, I had a file that got saved with 777 with a folder with 777 (byproduct of some hasty programming on my part). I came to visit my admin site one day, and I had a nice little message from a hacker.

    Now, thankfully this hack was nice enough not to do anything malicious. Hell, all he even did was comment out my page, and inserted his own. It was a warning message more than anything else. After some discussion with my host, he used a weakness not in mysite, but someone else on the server to get in.

    Moral of the story, do not leave yourself vulnerable like that. ESPECIALLY if you are on a shared host and not able to control all the variables.

  4. Neal V responds:
    Posted: November 10th, 2006 at 1:25 pm

    I don’t understand why a public folder would have to be set to executable anyway. If you are using the classic LAMP set up, or something similar, you should only have to worry about granting write permissions, nothing needs to be executable.

    Really, permissions is just another set of barriers. Folder permissions are not the first thing that a would-be cracker comes across in trying to bring down a site, nor is it the last barrier. Some people make all their folders read-only, except ones that are used for catching uploads. Of course that is pointless if you are using an FTP account with permissions to change file permissions.

    Look, bottom line is that folder permissions are good to have, but not the be-all and end-all. A cracker has to break through several other barriers before worrying about file permissions. But why give out permissions that aren’t necessary? That would be like giving all of your employees keys to the back door of your store, but not worrying because the building is alarmed. Can employees break in easily? No. But why give them any help?

  5. Adam responds:
    Posted: November 13th, 2006 at 3:01 pm

    I was using a method similar to what you described where I used FTP connection to alter the permissions, upload, change back to original. I found a better solution was to use a different package of PHP my host offered to run as my user rather than as NOBODY. Turns out this methos was much more secure for me.

    Granted, in creating an app for distribution, this does not work. But, I am heppy with it.

  6. David Zemens responds:
    Posted: November 14th, 2006 at 7:58 am

    “I’ve given up trying to make anything significant like a content management system for public consumption.”

    Does this mean that you are no longer going to offer the GBCMS to the public, Mike?

  7. Glenn responds:
    Posted: November 17th, 2006 at 5:44 am

    Mike, an interesting line of investigation.

    What we do with our blogs is to have a generic hardening script that (after any work, installation of plug ins etc):
    - changes owner and group of everything in the tree
    - sets permissions to 744 (and 755 for directories)
    - creates ‘null’ index.php files in directories that might not have them
    - opens up permissions for the upload directories only (to 777) to allow image uploads for posts.

    We have modified our template to store parameterised data in tables, to avoid the need to customise css or php files (e.g. addition of urchin, custom CSS). So theme directories can stay closed.

    This strategy was based on the following:

    The codex article doesn’t say it directly, but implies that 777 permissions on upload areas are harmless. Potentially image files could be altered/deleted (annoying, but not a disaster, and easy to recover from).

    If you are interested in the full Linux hardening script, let me know and I can send it to you.

    This is the section that creates null index.php files:

      #if an index.php file doesn't exist in each directory, create one
      for dir in `find . -type d -print`
         if [[ -e $dir/index.php ]]
           then echo "  $dir/index.php exists" > /dev/null
            # echo "  Creating $dir/index.php"
            cp /home/bin/index.php $dir


    Interested in any opinions on the strategy in the codex.

  8. chris kane responds:
    Posted: November 30th, 2006 at 8:47 pm

    hi, i just found my site a bit hacked by some script kiddie called ‘wildinc’, now, he only got into the one folder, the 777 one, he deleted it’s contents and replaced it with his own, so he’s found a way to access the folder from outside the site, security was tight (so i thought) and only certain file types were allowed, but even the files containing such security code were deleted, he left his calling card in an index.php file, he didn’t manage to get anywhere else on the site.

    when php is in Safe Mode, chmod() won’t work, i’m grappling with the FTP method but finding it a struggle.

    my answer (777 => “not safe”)

  9. chris kane responds:
    Posted: November 30th, 2006 at 9:30 pm

    ok, i tried this and it worked, this will only work with FTP enabled so if your php won’t connect and you know your details are right, your screwed, find a new host, or host yourself, but not over wireless it sucks.

    function changemode($xcite)
    $ftp_details = array(
    ftp_user_name => 'username',
    ftp_user_pass => 'password',
    ftp_user_root => '/public_html/',
    ftp_server => ''
    $path = "public";
    $mod = intval($xcite, 8);
       // extract ftp details (array keys as variable names)
       extract ($ftp_details);
       // set up basic connection
       $conn_id = ftp_connect($ftp_server);
       // login with username and password
       $login_result = ftp_login($conn_id, $ftp_user_name, $ftp_user_pass);
       // try to chmod $path directory
       if (ftp_site($conn_id, 'CHMOD '.$mod.' '.$ftp_root.$path) !== false) {
       else {
       // close the connection
    	return $success;
    // then call it where required, an example:
    changemode(777, directory);
    if (@copy("$tempname", "$fullfilename")) $done = "yes";
    changemode(755, directory);

    for those of you, like me, who were looking for a way to make an ‘un-hackable’ uploader, here’s the closest i got, now for a field test, good luck!

  10. chris kane responds:
    Posted: November 30th, 2006 at 9:30 pm

    that smily face ruined the code, click View Source to get the code without it.

  11. chris kane responds:
    Posted: November 30th, 2006 at 9:32 pm

    or maybe not, i just did and it’ll take you ages that way, instead, replace 8) with 8 ) (you can remove the space for tidiness if you like)

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.