Understanding Our Server Permissions

Home Knowledgebase Understanding Our Server Permissions

This article explains why our server permissions are setup uniquely from typical servers, how they got that way and how to troubleshoot issues.

 

The Why

If you’ve developed WordPress websites in the past, you may think there isn’t a problem relating to permissions and we’ve just over complicated it. But, unless your server uses sticky permissions with group write access, then all developers that work on that site are sharing the same username and password.

This is a poor security practice that can result in:

  • The website owner, or administrator, losing access to the site because a disgruntled developer took control.
  • ” ” because a developer failed to login too many times and so the server locked the user down.
  • If multiple developers are signed in at the same time many servers will automatically sign out one of them because it’s a best practice to only allow one connection at a time per user.
  • The log file that shows the exact commands a developer ran cannot be traced back to an individual person because multiple people were sharing a user account.
  • And probably more…

 

The Context

Our server relies on PHP as well as a module called PHP-FPM – which speeds up the processing of PHP pages.

 

The Problem

However, PHP-FPM requires that the group on all site directories is the native www-data user. But the site user is not, by default, apart of this group. Resulting in upload errors, permalink (AKA htaccess) write errors and more when administering a site within WordPress.

 

The Solutions

The solution (quick version) is to:

  1. Add the site user to the www-data group.
  2. Then to tell Virtualmin and NGinx that it should use that group when creating new files and directories.
  3. Then to change the octal permissions on all existing files and directories for the site to 770 (rwxrwx—) / 640 respectively.
  4. Then to set sticky permissions on the site’s parent directory and / or the overarching /home directory if you want it to apply to all sites on the server (which we do).

The exact and detailed steps are outlined further below.

 

Troubleshooting

You will need to be a user with sudo privileges to run these commands.

 

How do I know if my user has sudo privileges?

If you type sudo touch myTest.html it should prompt you for your password. If it does not, then you will get an error saying you are not in the sudoers list.

 

How do I get sudo privileges?

Only the root user or another user with sudo privileges can give you access. This can be done one of two ways:

  • From the command line: 
    • usermod -a -G sudo YourUsername
  • From within Webmin:
    • From the navigation menu on the left select System > Users & Groups
    • Select the user you want to add to the sudoers list.
    • The page will reload and you will see their profile settings.
      • IMPORTANT NOTE: There is a bug with Webmin that causes the username field to be replaced with the currently signed in user’s name instead of the user’s profile you’re viewing. You must delete the currently signed in users name and replace it with the one you want to edit.
    • Navigate down the page to the Groups section, and search in the list for sudo (you can also use the Cmd + f or Ctrl+ f to search the list).
    • Select it and add it to the box on the right.
    • Save the user.
    • Now that user can log out and log back in and they will have sudo privileges.

 

What are the steps involved in troubleshooting permissions related issues?

Step 1

First confirm what permissions the directory in question has by executing ls -lA. You should see something like this:

The first column states the octal permissions (drwxrwx--- which is the same as chmod 770 and means the user and group have read, write, and execute permissions), the 3rd and 4th column is the user (theporltandcompany) and the group (www-data) the last column is the directory. In this screenshot the permissions are 

 

Step 2

Sometimes permissions on the parent directory are correct, but one or more subdirectories or files are incorrect. To resolve this, you can reset the permissions by executing: 

  1. find /home/SITE/ -type d -exec chmod 770 {} \;
  2. find /home/SITE/ -type f -exec chmod 640 {} \;

In most cases, this fixes permissions related issues. However, if it reappears, this is likely because stick permissions were disabled.

 

What are sticky permissions?

When a file or directory is created, the owner is set to the person / user that created it. By default, the group is also set to that user as well. But PHP FPM and WordPress require it to be the same group that they are both in, which is www-data. So, if sticky permissions aren’t enabled, and you, PHP-FPM or WordPress create or modify a file or directory then the other users no longer have access to edit it because it’s owned by the one.

With sticky permissions enabled, it will, instead, inherit the group from it’s parent directory, which allows any user in that group permission to read, write and execute that directory or file.

 

How do I set sticky permissions?

Execute this command: chmod g+s /home

 

 

 

Setting Up

If you’re building a new server, or the troubleshooting steps above didn’t work, then you should continue reading how the server is setup so the above steps actually work.

There are six ingredients to get overcome this issue. Once they’re done, it will always work unless someone changes it. The only person who can change these things would be a user with sudo privileges and someone who – probably – did it knowingly.

 

  1. Set permissions on existing directories: find /home/site/ -type d -exec chmod 770 {} \;
  2. Set permissions on existing files: find /home/site/ -type f -exec chmod 640 {} \;
  3. In order for someone, within WordPress, to upload a file, WordPress has to have permission from the server to do that. Or the user will get an error during the upload process. This is normally done by setting the WordPress uploads directory octal permission to 0755 and setting the user and group to the website’s user. However, with these permissions any developer who would work on the system must be given the site’s Unix username and password. This prevents proper logging (so you can trace what a user has done) and it prevents site owners / administrators from removing that users access to the site in the future.
  4. Set Sticky Permissions
    1. When someone uploads a file through WordPress
  5. chmod g+s
  6. User and Group – The first ingredient is to ensure all files and directories have a group of www-data, and then their user is set to the 
    1. The first place to set this is in VirtualMin. This is because we rely on VM to create new domains. When it does this it creates new files and directories and sets the permissions on them. If we don’t tell it which ones to use, it uses the defaults and the system breaks. This is done in X file at line X by setting it to X.

 

Recommended Reading

  • http://permissions-calculator.org/



By
Categorized in:
This post is related to:

Home Knowledgebase Understanding Our Server Permissions

This article explains why our server permissions are setup uniquely from typical servers, how they got that way and how to troubleshoot issues.

 

The Why

If you’ve developed WordPress websites in the past, you may think there isn’t a problem relating to permissions and we’ve just over complicated it. But, unless your server uses sticky permissions with group write access, then all developers that work on that site are sharing the same username and password.

This is a poor security practice that can result in:

  • The website owner, or administrator, losing access to the site because a disgruntled developer took control.
  • ” ” because a developer failed to login too many times and so the server locked the user down.
  • If multiple developers are signed in at the same time many servers will automatically sign out one of them because it’s a best practice to only allow one connection at a time per user.
  • The log file that shows the exact commands a developer ran cannot be traced back to an individual person because multiple people were sharing a user account.
  • And probably more…

 

The Context

Our server relies on PHP as well as a module called PHP-FPM – which speeds up the processing of PHP pages.

 

The Problem

However, PHP-FPM requires that the group on all site directories is the native www-data user. But the site user is not, by default, apart of this group. Resulting in upload errors, permalink (AKA htaccess) write errors and more when administering a site within WordPress.

 

The Solutions

The solution (quick version) is to:

  1. Add the site user to the www-data group.
  2. Then to tell Virtualmin and NGinx that it should use that group when creating new files and directories.
  3. Then to change the octal permissions on all existing files and directories for the site to 770 (rwxrwx—) / 640 respectively.
  4. Then to set sticky permissions on the site’s parent directory and / or the overarching /home directory if you want it to apply to all sites on the server (which we do).

The exact and detailed steps are outlined further below.

 

Troubleshooting

You will need to be a user with sudo privileges to run these commands.

 

How do I know if my user has sudo privileges?

If you type sudo touch myTest.html it should prompt you for your password. If it does not, then you will get an error saying you are not in the sudoers list.

 

How do I get sudo privileges?

Only the root user or another user with sudo privileges can give you access. This can be done one of two ways:

  • From the command line: 
    • usermod -a -G sudo YourUsername
  • From within Webmin:
    • From the navigation menu on the left select System > Users & Groups
    • Select the user you want to add to the sudoers list.
    • The page will reload and you will see their profile settings.
      • IMPORTANT NOTE: There is a bug with Webmin that causes the username field to be replaced with the currently signed in user’s name instead of the user’s profile you’re viewing. You must delete the currently signed in users name and replace it with the one you want to edit.
    • Navigate down the page to the Groups section, and search in the list for sudo (you can also use the Cmd + f or Ctrl+ f to search the list).
    • Select it and add it to the box on the right.
    • Save the user.
    • Now that user can log out and log back in and they will have sudo privileges.

 

What are the steps involved in troubleshooting permissions related issues?

Step 1

First confirm what permissions the directory in question has by executing ls -lA. You should see something like this:

The first column states the octal permissions (drwxrwx--- which is the same as chmod 770 and means the user and group have read, write, and execute permissions), the 3rd and 4th column is the user (theporltandcompany) and the group (www-data) the last column is the directory. In this screenshot the permissions are 

 

Step 2

Sometimes permissions on the parent directory are correct, but one or more subdirectories or files are incorrect. To resolve this, you can reset the permissions by executing: 

  1. find /home/SITE/ -type d -exec chmod 770 {} \;
  2. find /home/SITE/ -type f -exec chmod 640 {} \;

In most cases, this fixes permissions related issues. However, if it reappears, this is likely because stick permissions were disabled.

 

What are sticky permissions?

When a file or directory is created, the owner is set to the person / user that created it. By default, the group is also set to that user as well. But PHP FPM and WordPress require it to be the same group that they are both in, which is www-data. So, if sticky permissions aren’t enabled, and you, PHP-FPM or WordPress create or modify a file or directory then the other users no longer have access to edit it because it’s owned by the one.

With sticky permissions enabled, it will, instead, inherit the group from it’s parent directory, which allows any user in that group permission to read, write and execute that directory or file.

 

How do I set sticky permissions?

Execute this command: chmod g+s /home

 

 

 

Setting Up

If you’re building a new server, or the troubleshooting steps above didn’t work, then you should continue reading how the server is setup so the above steps actually work.

There are six ingredients to get overcome this issue. Once they’re done, it will always work unless someone changes it. The only person who can change these things would be a user with sudo privileges and someone who – probably – did it knowingly.

 

  1. Set permissions on existing directories: find /home/site/ -type d -exec chmod 770 {} \;
  2. Set permissions on existing files: find /home/site/ -type f -exec chmod 640 {} \;
  3. In order for someone, within WordPress, to upload a file, WordPress has to have permission from the server to do that. Or the user will get an error during the upload process. This is normally done by setting the WordPress uploads directory octal permission to 0755 and setting the user and group to the website’s user. However, with these permissions any developer who would work on the system must be given the site’s Unix username and password. This prevents proper logging (so you can trace what a user has done) and it prevents site owners / administrators from removing that users access to the site in the future.
  4. Set Sticky Permissions
    1. When someone uploads a file through WordPress
  5. chmod g+s
  6. User and Group – The first ingredient is to ensure all files and directories have a group of www-data, and then their user is set to the 
    1. The first place to set this is in VirtualMin. This is because we rely on VM to create new domains. When it does this it creates new files and directories and sets the permissions on them. If we don’t tell it which ones to use, it uses the defaults and the system breaks. This is done in X file at line X by setting it to X.

 

Recommended Reading

  • http://permissions-calculator.org/

About

Since 2005 we've been offering digital and content marketing strategy and implementation. Including website development, search engine optimization and marketing, search marketing and more.

Continue Reading »

Contact

Email

us@theportlandcompany.com

Phone

503-567-9561

Follow

  • Logo for The Portland Company with a Coyote
    Thank you for using our site. x