Never use 777 to solve a permission issue

Web Applications have a specific setup when it comes to Permission and Ownership. Magento is no exception to this.

Over the years, I’ve seen many people suggesting 777 to resolve a Permission issue. Unless specifically told to do this by Magento - You should never do this.

What does 777 mean?

777 represents what access an Owner, Group and Public have to files/directories. In the case of 777, it means:

  • The Owner can Read, Write and Execute
  • The Group can Read, Write and Execute
  • The Pubic can Read, Write and Execute (Security Alarm Bells should be going off here!)

Therefore, you relinquish your security.

Example 1 (Worst Case Scenario)

Your Magento 2 storefront is made from HTML, PHP, CSS, JS, etc… These files should only be Writable by Magento of Apache. However, you run into an issue setting your permissions. Therefore you set your Files/Directories as 777 to get round it.

A bad actor comes along and notes that your frontend files are vulnerable. They quickly realise that they can edit all of your files without being challenged. So, they manipulate your store checkout to start scraping credit card details from your customers.

2 months later, you receive a fine for breach of PCI Compliance and your Payment Providers revoke your ability to take payments. Google blacklists your site for containing malware. So, with a huge fine and no way to take payments, you’re forced to shut down.

Now let’s assume you fix this issue quickly and satisfy PCI DSS. You’re still accountable for the original fine. But you are now also susceptible for a GDPR fine for leaking customer sensitive information. This means you are legally obliged to contact each of your customers that spent with you whilst you were vulnerable to inform them that their data was compromised. PR Nightmare.

Example 2 (Ref: askubuntu.com)

[email protected]:~/Projects/AskUbuntu/20105$ cd ..
[email protected]:~/Projects/AskUbuntu$ chmod 0777 20105
[email protected]:~/Projects/AskUbuntu$ cd 20105/
[email protected]:~/Projects/AskUbuntu/20105$ ls -lah
total 8.0K
drwxrwxrwx 2 marco marco 4.0K 2011-01-04 20:32 .
drwxr-xr-x 3 marco marco 4.0K 2011-01-04 20:32 ..
[email protected]:~/Projects/AskUbuntu/20105$ touch test
[email protected]:~/Projects/AskUbuntu/20105$ chmod 0666 test 

So far I have created a folder and made a file with “bad” permissions (777 and 666). Now I’ll switch into another user and try to manipulate those files.

[email protected]:~/Projects/AskUbuntu/20105$ sudo su - malicious
[email protected]:~$ cd /home/marco/Projects/AskUbuntu/20105
[email protected]:/home/marco/Projects/AskUbuntu/20105$ ls
test
[email protected]:/home/marco/Projects/AskUbuntu/20105$ ls -lah
total 8.0K
drwxrwxrwx 2 marco marco 4.0K 2011-01-04 20:33 .
drwxr-xr-x 3 marco marco 4.0K 2011-01-04 20:32 ..
-rw-rw-rw- 1 marco marco    0 2011-01-04 20:33 test
[email protected]:/home/marco/Projects/AskUbuntu/20105$ touch bad
[email protected]:/home/marco/Projects/AskUbuntu/20105$ echo "OVERWRITE" > test 
[email protected]:/home/marco/Projects/AskUbuntu/20105$ cat test 
OVERWRITE

As this “malicious” user I was able to place files into the directory and inject text into already existent files. Whereas below, in a directory with 755 and files with 644, I am able to see inside files and directories but I can not edit the files nor create new ones:

[email protected]:/home/marco/Projects/AskUbuntu/20105$ cd /home/marco/Projects
[email protected]:/home/marco/Projects$ touch hey
touch: cannot touch `hey': Permission denied

What are the penalties for non-compliance?

The payment brands may, at their discretion, fine an acquiring bank $5,000 to $100,000 per month for PCI compliance violations. The banks will most likely pass this fine along until it eventually hits the merchant. Furthermore, the bank will also most likely either terminate your relationship or increase transaction fees. Penalties are not openly discussed nor widely publicized, but they can be catastrophic to a small business. It is important to be familiar with your merchant account agreement, which should outline your exposure.

What is the maximum GDPR fine?

There are two tiers of administrative fine for non-compliance with the GDPR:

  1. Up to €10 million, or, in the case of an undertaking, 2% of annual global turnover – whichever is greater; or
  2. Up to €20 million, or, in the case of an undertaking, 4% of annual global turnover – whichever is greater.

GDPR breach fines are discretionary rather than mandatory. They must be imposed on a case-by-case basis and should be “effective, proportionate and dissuasive”.

If I can’t use 777 then how do I fix my issue?

Ideally, you should seek a better understanding of Unix Permissions. A fundamental knowledge of administrating a web server. Once you’ve understood this, then refer to the Official Magento Documentation. At this point, you will confidently be able to follow this useful tutorial that I put together: How to diagnose and fix Ownerships and Permission issues.

References: