Website Permissions on Linux: 750 and 650 VS 755 and 644

Permission management on a Linux operating system is a critical component of the security and integrity of a website hosted on it. When talking about restoring permissions to a virtual host (vhost) on Linux, one almost universally comes across the recommendation to use 755 for directories and 644 for files. These indications, however, do not take into account important safety considerations and are ABSOLUTELY WRONG.

The importance of separation of privileges in Linux

Linux is an operating system that bases much of its security model on the separation of privileges. This separation is a fundamental principle that implies that each process should operate using the fewest privileges necessary to carry out its task. This minimizes the consequences of an exploit or misconfiguration. For example, in a shared hosting environment, if a site is compromised, the violation of a particular vhost must not allow the attacker to read, write or execute files belonging to other users, which on Linux are uniquely identified by UserID (UID ) and GroupID (GID).

This security architecture prevents privilege escalation and contains damage, maintaining overall system integrity.

rwx permissions for users and groups and numeric notation

Permissions on Linux are divided into three categories: owner (user), group (group) and others (others). 'rwx' stands for read, write and execute. These permissions determine what users can do with a given file or directory:

• r (read): Allows viewing of the contents of the file/directory.
• w (write): Allows modification of the file/directory.
• x (execute): Allows file execution or directory navigation.

These permissions are represented numerically, where 4 stands for 'read', 2 for 'write' and 1 for 'execute'. A permission like 777 would allow everyone (user, group, and others) full privileges on a file or directory.

The combination of these numbers creates permission sets:

• 7: Full access (rwx) – Read, write and execute.
• 6: Read and write (rw-) – Read and write, but no execution.
• 5: Read and execute (rx) – Read and execute, but no writing.
• 4: Read only (r–) – Read only.
• 0: No permissions (–x) – No permissions.

For each file and directory, we can define separate permissions for user, group and others:

• First number: Owner (user) permissions.
• Second issue: Group permissions.
• Third issue: Permissions for others (users not in the group and not owners).

Example of Permissions Configuration

• Directory: 750
  • Owner (user): rwx
  • Group: rx
  • Others-
• Fillet: 640
  • Owner (user):rw-
  • Group:r–
  • Others-

This configuration ensures that:

• The owner has full control over their files.
• The group (which may include the web server process) can read files and navigate directories, but not modify them.
• Other users have no access, protecting your data in a shared hosting environment.

The underlying error of permits 755 and 644

The 755 permission for directories allows all users to read and execute the files in them, while the 644 permission for files allows everyone to read them. This setting does not comply with the principle of least authorization. The last group, “others,” which includes any user not identified as the owner or part of the group, should not have permissions on these files or directories. The safest permissions should therefore be 750 for directories and 640 for files, where the last number (representing “others”) is set to 0, denying any permissions.

We find official indications of this type around from important hosting companies:

Keliweb :

SiteGround:

ServerPlan:

TopHost:

Kinsta:

and we could continue almost endlessly, including more than 90% of the world's hosting providers.

The origin of error and original sin

When it comes to IT security, especially in the hosting sector, every little detail can make the difference. Assigning permissions to files and directories of a website hosted on a Linux server is a critical aspect that is often underestimated or handled suboptimally. The basic error in permission management, an "original sin" in the system context, arises from an incomplete understanding of the interaction between the user who owns the vhost and the web server group.

Traditional Confusion

Traditionally, most tutorials and guides — including some provided by well-known competitors in the industry — have limited themselves to suggesting standardized permission settings, such as 755 for directories and 644 for files. These generalized instructions do not take into account a crucial point: the web server user, who in environments such as cPanel is generally identified as 'nobody', should ideally be placed within the ownership group of the hosted files.

The Inadequacy of the Standard Configuration

Without this strategic inclusion, a permissive configuration tends to be used to allow the web server process to read files, especially static HTML files. Read (and sometimes also execute) permissions are assigned to the "others" category, i.e. all users not belonging to the file owner's group. This is a palliative that solves the accessibility problem but opens potential security holes. In fact, if an attacker were to gain even limited access to the system, he or she would find a larger attack surface than necessary.

There are those who argue that a server, configured even with these looser permissions, still remains quite secure and that the overall functionality is not affected. However, it is a short-sighted view in the cybersecurity landscape. It is essential that industry professionals, especially those with years of experience, adhere to the principle of “LESS IS MORE”. This principle translates into a policy of minimizing privileges: each user should have only the permissions strictly necessary to carry out their functions, no more and no less.

That's why, outside of the owner and his group, “others” — all other users of the system — should not have the ability to perform any actions on the files. You should always aim for a permission configuration that guarantees the highest possible level of security, compatible with the functioning of the hosted applications. This means that the last digit of permissions, the one that regulates the actions of “others”, should be set to zero (750 for directories and 640 for files), creating an environment in which access is strictly controlled and limited .

The correct way of permissions

In the context of managing a web server, the correct assignment of file and directory permissions is a fundamental component to guarantee the security of the system without compromising its functionality. To achieve this objective, it is essential to follow a procedure that includes both operational flexibility and the necessary rigidity in terms of access control.

Integration of UID into Web Server Group

The optimal strategy is to add the virtual host (vhost) UID to the group used by the web server, which can vary depending on the configuration and the web server used (for example, 'apache', 'www-data', 'nobody' or 'nginx'). This step is crucial because it allows you to manage permissions in a granular way, ensuring that the vhost resources are accessible from the web server in the way necessary and with the appropriate limitations.

Configuring Permissions

Once you've integrated the user into the appropriate group, it's time to set permissions. Directory permissions should be set to 750, allowing the owner full access (read, write, execute), the group (in this case the web server) the ability to read and traverse the directories, and no access to other users. Similarly, file permissions should be set to 640, allowing the owner to read and write, the web server to read the files, and again, denying all access to others.

Practical Example

Let's imagine we have a user named pippo.it. By adding pippo.it to the web server group, such as 'nobody' or apache or ww-data for Apache, or nginx for the NGINX Web Server, it will ensure that the web server can perform all necessary operations such as reading files and serving them to users finals through the browser. These correctly assigned permissions prevent other system users, who are not part of this group, from having any form of access to files and resources associated with other vhosts. This is particularly important in shared hosting environments, where separation between the resources of different users must be absolutely guaranteed.

Safety as a priority

The adoption of these permissions ensures a balance between operation and security. The web server can smoothly perform its operations, such as serving pages and managing dynamic applications, but without having the ability to alter the files, a restriction that minimizes the risk of damage in the event of a vulnerability in the web server software. At the same time, other users of the system are completely isolated from the resources of pippo.it, a preventative measure against cross-compromise between vhosts.

Conclusion

Reviewing the management of permissions on files and directories is a necessity for the security and efficiency of a website hosted on a Linux server. Moving from a permissive 755/644 configuration to a more restricted and secure 750/640 significantly reduces the risk of compromise through inappropriate permission sharing. It is critical to understand the role of users and groups and how they interact with file permissions to maintain a secure web environment, especially in a shared hosting setup.

While more secure permissions configuration may seem less convenient, its positive impact on hosting security is undeniable. Implementing correct permissions, along with careful configuration of the web server group, ensures that only authorized entities have access to files and directories, thus protecting user data and the integrity of the server itself. With security as a priority, 750 permissions for directories and 640 for files should be the standard for any aware and responsible system administrator.