Whenever I have folder permissions issue on my Ubuntu OS, I usually give the
777 permission for the certain folder. I often do this in the development environment.
In some situations, I have already given this type of permission in a production environment on a Linux server, where I run my applications written in PHP.
For example, when I had a specific problem writing upload files to the
public/uploads folder of a certain system, I gave permission
777 on this folder.
But I always see recommendations that we should use permission
644 , because using
777 is dangerous.
But in what sense would that be dangerous?
Why do more experienced programmers always recommend using other values for folder permissions in production instead of
For example, I've heard that a person can have problems with attacks on a web application if there is a
777 write permission on a certain folder. That's true?
It would also be nice if the answer could explain better about the differences between
777 permissions to a file you make all users able to read, write and execute the same.
This means that any vulnerability in your system allows an attacker to do whatever they want with that file. Worse still, with the combination of write and read permissions, an attacker with sufficient knowledge of your system can unknowingly cause another privileged user to do something.
An illustrative example
Bob is the sysadmin responsible for a JBoss server. Bob's JBoss is running as user
jboss . His application has a harmless script that copies files from a business
upload folder to an apache context folder (
apache user) optimized to serve static files; this script runs as user
jboss . Sounds like something you see around, doesn't it? For example, for uploading avatars and the like.
Let's say Bob, not wanting to struggle with access permissions between
apache went there and ran
chmod 777 on the apache context folder. With that the script in question, even running with the
jboss user, can write files in the apache folder without being disturbed. Sounds harmless right?
Then Bob started having problems dealing with these
jboss user files inside a folder that belongs to
apache . Apache did not display the images copied by the script . Bob, in a hurry, went over there and changed his script to run a
Mallory then verifies that PHP is installed on Apache; running even in the static images folder… Again Bob didn't see the need to keep messing with Apache configuration files since the folder in question would only have images.
- Opens Chrome's development tools and modifies Alice's validation function to allow
.phpfile upload .
- Create any PHP script , for example, to delete or steal all images from Bob's server.
- Upload the file from Chrome
- Wait for Bob's script to run
- Run the PHP script through the Apache context folder.
apache user is now running Mallory's script . Mallory just gained access to Apache through a vulnerability in an application running on JBoss.
Generalizing the story points:
- Solving a problem using
chmod 777often creates other problems that call for
chmod 777(permissions are there for a reason)
chmod 777gives access to writing and executing a file. This combination opens the door to various types of exploits .
chmod 777means that your file can be read, written and executed by any user. This means that any user who is compromised will be able to do whatever they want with the file/folder.
- Software components interact in non-trivial ways and security flaws accumulate across layers (Alice didn't validate files on the server-side of her application, Bob didn't disable PHP in Apache's context folder, and even wrote a lousy script ). As much as you trust your applications, it is important to maintain security at all layers and that includes file system permissions.