I'm writing installer for my PHP web app. It requires user to change permissions of a few files and directories (config.php, cache, uploads, .htaccess) to 777 (so that it's writable). I've seen in many applications that installer requires user to revert permissions (for config.php and such) back to 644.

Why is it so important? Why can't I just leave it with 777? I guess it's some kind of security concern, but what exactly can happen if I leave those files writable?

  • a quick google search comes up with these unix permissions tutorials: dartmouth.edu/~rc/help/faq/permissions.html and albany.edu/faculty/gms/homepage101/unix_permissions.html – cas May 1 '11 at 14:13
  • I know what unix permission are. Just somehow haven't figured out what I should have about them. – radex May 1 '11 at 17:32
  • that's why the tutorials - they're a good overview of how perms work and what the individual bits actually mean in practice. i.e. help to transform knowledge into understanding. – cas May 1 '11 at 22:18
  • I haven't seen reason to read a tutorial about something I understand (or thought I understand). Sorry for such a noob question. – radex May 2 '11 at 12:53

PHP scripts run on the webserver. Leaving the permissions that way will make your web server user (www-data or apache) able to write on those files. In case of your script has some bug or vulnerability, those permissions will allow the web server (and thus, external agents) to change the contents of the files and filesystem. Things that can happen:

  • Loss of everything (the write permission is also permission to delete the files);
  • Addition of unwanted stuff: some attacks aim to add data to your site, like malicious scripts, fake pages or scripts for physhing and spamming. Since your webserver can write files to the filesystem, data can be uploaded anywhere it has the permissions.

So, yeah, it's a horrible idea to leave permissions on that state.

  • Oh, that's so obvious. I don't know why I haven't thought of that possiblity (given my 5 year experience in web development). I'm such a noob ;) – radex May 1 '11 at 13:25

777 is especially bad. It means anyone can delete files as well as create them. I create a file, you delete that file.

If you must use 777, then use 1777 -- this tells the OS to only allow the owner of the file to delete it.

Otherwise it is exactly as coredump said -- a bug in a script that allows me to write out new files or overwrite existing files allows me to do anything I want to your web server because I overwrite / create files as apache / nobody / www-data then the web server will be serving my malicious content instead of the original content.

Ideally the web server process can't write to the directories it reads from to avoid such problems.


anyone who has access to that directory (e.g. via ftp) can read, write and execute them. you, as the developer, have to go through the scenarios of the intention of use and close potential security holes...


Other users in that server/workstation can modify the file. Example, using desktop Ubuntu, make /home 777 and it can be deleted or modified by any user.

777 is especially a security risk when you are in a shared hosting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.