On this page
When multiple websites share one Linux server, each site’s files should be separated by ownership and permissions. To isolate a website directory, the server must prevent one website’s processes or users from freely reading or modifying another site’s files.
This is a key part of Linux permission hardening on shared hosting servers. Proper ownership, directory permissions, application users, and web server configuration can reduce the impact of a compromised website and help prevent cross tenancy malware infection from spreading between sites.
What Does It Mean to Isolate Website Directory?
Isolating a website directory means limiting which users and processes can access the files belonging to that website.
A typical multi-tenant server may contain several websites:
/home/
├── site-a.com/
├── site-b.com/
├── site-c.com/
└── site-d.com/If every website process can read and write every directory, one compromised site can become a much larger security problem.
A better model is:
site-a.com → site-a user → site-a files
site-b.com → site-b user → site-b files
site-c.com → site-c user → site-c filesThe goal is not to make every directory completely inaccessible. The goal is to give each website the minimum access it needs to operate.
CyberPanel supports multi-user hosting through separate users, websites, ownership, and ACLs. Its current website creation workflow also assigns each website an owner and its own document root.
Why Is Website Directory Isolation Important?
A shared server creates a larger security boundary than a single-site server.
Imagine a server hosting 20 WordPress websites. If one WordPress installation is compromised and the web process can freely access all 20 websites, the attacker may be able to modify files outside the original site.
Directory isolation reduces this risk.
It can help limit:
- Unauthorized file reads
- Unauthorized file modification
- Malware spreading between websites
- Cross-site configuration access
- Accidental changes between customer accounts
- Damage caused by a compromised application
This does not make a server immune to malware. A compromised root account, vulnerable privileged service, or incorrectly configured web server can bypass ordinary file permissions.
The purpose is to create smaller security boundaries so that one compromised application has fewer ways to affect unrelated websites.
How Does Linux Isolate Website Files?
Linux uses several mechanisms to control access:
- File ownership
- User IDs
- Group ownership
- Read, write, and execute permissions
- ACLs
- Process privileges
- Web server configuration
For example:
Owner: siteuser
Group: siteuser
Directory: /home/siteuser/public_html/The website process should operate with the privileges required for that website rather than unrestricted root privileges.
Linux permissions use three primary access classes:
| Class | Meaning |
|---|---|
| Owner | The user who owns the file |
| Group | Users belonging to the file’s group |
| Others | Everyone else |
Each class can have:
| Permission | Meaning |
|---|---|
| Read | View file contents or directory entries |
| Write | Modify files or create/delete directory contents |
| Execute | Execute a file or access a directory |
CyberPanel’s Linux file permissions guide explains the same owner, group, and others model and the numeric chmod notation used to manage it.
What Permissions Should a Website Directory Have?
There is no universal permission number that is correct for every application.
A common starting point for website directories is:
chmod 755 /home/siteuser/public_htmlThis gives the owner read, write, and execute access while giving the group and others read and execute access.
For regular files, a common starting point is:
chmod 644 filename.phpThis gives the owner read and write access while group and others receive read access.
However, do not blindly apply 755 or 644 to an entire website.
Some applications require specific files or directories to be writable by the application process. Upload directories, cache directories, temporary directories, and application-specific storage paths may need different permissions.
The correct approach is to grant the minimum permissions required by the application.
Example Permission Model
| Resource | Example Permission | Purpose |
|---|---|---|
| Website directory | 755 | Allows directory traversal |
| Normal files | 644 | Owner can modify, others can read |
| Private configuration | 640 or stricter | Limits unnecessary access |
| Writable upload directory | Application-specific | Allows required uploads |
| Backup files | Restricted | Prevents public or cross-user access |
These are starting points, not universal rules.
How to Check Website Ownership and Permissions
Before changing anything, inspect the existing configuration.
Use:
ls -ld /home/siteuserThen inspect the document root:
ls -ld /home/siteuser/public_htmlFor individual files:
ls -l /home/siteuser/public_html/You can also check ownership recursively:
find /home/siteuser/public_html -maxdepth 2 -printf '%u:%g %m %p\n'This helps identify files that have unexpected owners or overly broad permissions.
For example, you might find:
siteuser:siteuser 755 /home/siteuser/public_html
siteuser:siteuser 644 /home/siteuser/public_html/index.phpThe exact ownership and permissions on a CyberPanel installation can vary depending on the operating system, PHP configuration, website setup, and CyberPanel version.
Do not change ownership simply because a command from another server uses a different user.
How to Isolate a Website Directory on Linux
A practical isolation process starts with identifying the website owner and document root.
Step 1: Identify the Website User
Check the user associated with the website:
id siteuserThis displays information such as the user’s UID and groups.
On a multi-tenant server, each website should be associated with the intended hosting account rather than sharing unnecessary privileges with unrelated sites.
CyberPanel provides user and ACL management for hosting accounts, including separate user, reseller, and administrator roles.
Step 2: Identify the Document Root
Find the website’s document root.
A CyberPanel website normally has its own website directory.
For example:
/home/siteuser/public_html/Do not assume this exact path for every installation. Check the actual website configuration before running permission commands.
CyberPanel’s current website management interface provides access to the website’s File Manager, SSH, FTP, configuration, and ownership settings.
Step 3: Check the Directory Owner
Run:
ls -ld /home/siteuser/public_htmlYou should see the configured owner and group.
For example:
drwxr-xr-x siteuser siteuser public_htmlIf an unrelated user owns the directory, investigate the reason before changing it.
Step 4: Check Files Inside the Directory
Run:
find /home/siteuser/public_html -maxdepth 2 -lsLook for files owned by unexpected users.
A common problem after manual deployments or root-level file operations is that application files become owned by root.
That can cause both security and application problems.
Step 5: Correct Ownership Carefully
If you have confirmed that the website should be owned by siteuser, an administrator might use:
chown -R siteuser:siteuser /home/siteuser/public_htmlDo not run this command blindly.
The correct owner and group depend on your server configuration. Some applications intentionally use a different service account or group.
CyberPanel also provides a Fix Permissions function in its File Manager. Its documentation specifically notes that incorrect file and folder permissions can interfere with website operations such as SSL validation.
For CyberPanel-managed websites, use the panel’s permission tools when appropriate instead of manually overriding the panel’s expected ownership model.
How Does Linux Permission Hardening Prevent Cross-Site Access?
The key principle is simple:
A website should not receive permission to modify another website’s files.
Suppose:
/home/site-a/public_html/
/home/site-b/public_html/are owned by different users.
If site-a is compromised, Linux can prevent that account from writing to site-b when the permissions are correctly configured.
Conceptually:
Compromised Site A
|
v
site-a user
|
+----> Site A files ALLOWED
|
+----> Site B files DENIEDThis is much safer than allowing both sites to operate with a shared, highly privileged account.
However, directory permissions are only one layer. The web server, PHP handler, scheduled jobs, FTP accounts, SSH access, plugins, and privileged services also need to respect the same separation model.
How Do You Prevent Cross-Tenancy Malware Infection?
To prevent cross tenancy malware infection, start by limiting what each website account can access.
A compromised application should not automatically gain write access to neighboring websites.
Use these controls together:
- Separate website users
- Correct file ownership
- Restricted directory permissions
- Separate application processes where supported
- Limited SSH and FTP access
- Secure PHP configuration
- Updated CMS software
- Malware scanning
- Web application firewall rules
- Regular backups
- Resource isolation
No single control provides complete isolation.
For example, ModSecurity can inspect HTTP requests and block certain malicious patterns, but it does not replace Linux filesystem permissions. OpenLiteSpeed supports ModSecurity, and CyberPanel provides controls for managing it.
Likewise, Linux permissions cannot stop an attacker from exploiting a vulnerable WordPress plugin through normal web requests. They reduce what the compromised process can do after exploitation.
What Is the Role of OpenLiteSpeed in Website Isolation?
OpenLiteSpeed is responsible for serving the websites, but filesystem access ultimately depends on the operating system and the identity under which the relevant process operates.
This makes OpenLiteSpeed user directory permissions an important part of a broader hosting security model.
The important question is:
Which Linux user does the website process operate as, and what can that user access?
If a process serving Site A can write to Site B’s directory, filesystem isolation is already weakened.
If Site A’s process can access only the files required by Site A, a compromise has a smaller blast radius.
OpenLiteSpeed also supports per-site resource controls. CyberPanel’s current resource limits documentation describes OpenLiteSpeed cgroups and user-level CPU, memory, I/O, and process limits.
Resource limits do not replace filesystem permissions, but they add another layer of tenant separation.
How Should OpenLiteSpeed User Directory Permissions Be Configured?
Do not treat OpenLiteSpeed configuration and Linux filesystem permissions as the same thing.
OpenLiteSpeed determines how requests are routed to websites and how application processes are handled. Linux decides whether those processes can actually read, write, or traverse particular filesystem paths.
A secure multi-tenant design therefore looks like:
Internet
|
v
OpenLiteSpeed
|
+---- Website A
| |
| +---- Site A user
|
+---- Website B
| |
| +---- Site B user
|
+---- Website C
|
+---- Site C userEach site’s filesystem access should remain limited to what that application requires.
Avoid giving every website access to:
/home/or unrelated customer directories simply because doing so makes a configuration easier.
Convenience should not override tenant boundaries.
Should Website Directories Be Set to 777?
No.
Avoid using:
chmod -R 777 /home/siteuser/public_htmlas a general solution for permission problems.
777 gives read, write, and execute permissions to the owner, group, and everyone else.
On a multi-tenant hosting server, that can turn a permission problem into a security problem.
It may allow unrelated users or processes to modify files that should be protected.
If an application reports a permission error, determine which file or directory actually needs write access and grant only the required permission.
For example, instead of making an entire application writable, identify its required upload or cache directory.
How Can You Find World-Writable Website Files?
You can search for world-writable files with:
find /home/siteuser/public_html -type f -perm -002 -lsTo find world-writable directories:
find /home/siteuser/public_html -type d -perm -002 -lsThese commands identify files and directories where the “others” write bit is enabled.
That does not automatically mean every result is malicious or incorrectly configured. Some applications intentionally require specific permissions.
Treat the results as an audit list.
How Can You Find Files Owned by Root?
Run:
find /home/siteuser/public_html -user root -lsIf you find root-owned files inside a website, investigate how they got there.
Possible causes include:
- Manual root-level deployment
- Migration
- Restore operation
- Installation script
- Backup restoration
- Incorrect ownership changes
Do not simply run a recursive chown without understanding your application and hosting configuration.
How Should Configuration Files Be Protected?
Configuration files often contain sensitive information.
For example, a CMS configuration may contain:
- Database credentials
- API keys
- Secret tokens
- Encryption keys
- Application settings
These files should not be more readable than necessary.
For a specific application, the correct permissions depend on how the application and PHP process access the file.
A useful rule is:
Protect secrets without breaking the application’s required access.
You can inspect a sensitive file with:
ls -l /path/to/config.phpThen verify:
- Who owns it?
- Which group owns it?
- Who can read it?
- Who can write it?
- Does the application actually need those permissions?
Does Directory Permission Isolation Stop Malware Completely?
No.
This distinction is important.
Directory isolation can reduce the damage caused by a compromised website, but it does not guarantee complete protection.
An attacker may still exploit:
- The compromised website
- Vulnerable plugins
- Vulnerable themes
- Stolen credentials
- Weak SSH authentication
- Vulnerable server software
- Misconfigured services
- Privileged applications
If an attacker obtains root-level access, normal website-user permissions no longer provide the same protection.
That is why Linux permission hardening should be part of a layered security strategy.
CyberPanel’s current security documentation and release history also show that permission handling is an active part of the platform’s security and maintenance work, including fixes related to permission races, Ubuntu permission issues, and child-domain permissions.
How Does CyberPanel Help With Multi-Tenant Security?
CyberPanel provides several controls that can support a multi-tenant hosting environment.
Separate Users and ACLs
CyberPanel supports administrator, reseller, and user ACLs. Custom ACLs can also restrict which panel functions an account can access.
Separate Website Ownership
When creating a website, CyberPanel allows an owner to be selected. The website receives its own document root and related configuration.
File Manager
The website management interface provides File Manager access for managing files, while also warning that file, SSH, and FTP changes can immediately affect the live website.
Resource Isolation
OpenLiteSpeed cgroups can apply CPU, memory, I/O, and process limits to users. This addresses resource exhaustion separately from filesystem access.
Security Controls
ModSecurity can provide an additional application-layer defense against malicious HTTP requests.
These controls work together. None should be treated as a replacement for the others.
A Practical Multi-Tenant Security Checklist
Before putting multiple websites on the same Linux server, review this checklist:
| Security Layer | What to Check |
|---|---|
| User separation | Each website uses the intended hosting account |
| Ownership | Files belong to the correct user/group |
| Directory permissions | Unnecessary write access is removed |
| File permissions | Sensitive files are not world-writable |
| PHP/application access | Processes receive only required access |
| SSH | Access is limited to authorized users |
| FTP | Accounts are restricted to required directories |
| OpenLiteSpeed | Virtual hosts point to the correct document roots |
| Resource limits | CPU, memory, I/O, and process limits are appropriate |
| ModSecurity | Application-layer protection is configured where appropriate |
| Updates | CMS, plugins, PHP, OpenLiteSpeed, and CyberPanel stay updated |
| Backups | Remote, tested backups are available |
For broader server protection, you can also review CyberPanel’s guide on security hardening for modern web hosting.
What Should You Do After Changing Permissions?
Always test the website.
Check:
- Homepage
- WordPress admin
- Login
- Media uploads
- Plugin installation
- Theme updates
- Contact forms
- Cron jobs
- Cache
- SSL renewal
- Application logs
A permission change can solve one security issue while breaking another part of the application.
If a CyberPanel website suddenly develops permission-related problems, the File Manager’s Fix Permissions function can help restore the expected website permissions.
For important production sites, create a verified backup before making large ownership or permission changes.
Best Practices for Isolating Website Directories
Keep these rules in mind:
Give Each Website Its Own User
Do not use one shared Linux account for unrelated tenants when your hosting architecture supports separate accounts.
Use Least Privilege
Give each process and account only the permissions it needs.
Avoid 777 Permissions
Do not use broad write permissions as a shortcut for application errors.
Audit Ownership
Look for files owned by unexpected users, especially root.
Protect Configuration Files
Restrict access to files containing database passwords, API keys, and other secrets.
Separate Writable Directories
If an application needs uploads or cache storage, make only the required locations writable.
Limit SSH and FTP
A user who does not need shell or FTP access should not receive it.
Monitor for Changes
Unexpected file modifications can indicate a compromised application.
Keep Backups
If malware changes a website, a clean backup can provide a recovery point.
Test the Isolation
Do not assume that websites are isolated because they are stored in different directories. Verify the actual ownership, permissions, process users, and application configuration.
Frequently Asked Questions
What does it mean to isolate a website directory?
It means restricting a website’s files so that only the required users and processes can access them. The goal is to prevent unrelated accounts or applications from reading or modifying the site’s data.
Can Linux permissions prevent malware from spreading between websites?
They can reduce the ability of a compromised website to modify files belonging to other websites. They cannot stop every type of malware or protect against attacks that gain higher privileges.
What permissions should website files have?
There is no single correct setting for every application. 644 for files and 755 for directories are common starting points, but the application’s ownership, process user, and write requirements must be considered.
What are OpenLiteSpeed user directory permissions?
They are the Linux filesystem permissions that determine what the user or process serving an OpenLiteSpeed website can access. OpenLiteSpeed routing alone does not replace Linux filesystem access controls.
Is chmod 777 safe for website directories?
Generally, no. It grants read, write, and execute permissions to everyone and can weaken isolation on a multi-tenant server.
Can CyberPanel isolate multiple websites?
CyberPanel supports separate users, website ownership, ACLs, website document roots, and OpenLiteSpeed resource controls. The actual level of isolation still depends on correct configuration and the server’s operating environment.
Final Takeaway
To isolate a website directory, start with separate users, correct ownership, least-privilege permissions, and controlled application access. On a multi-tenant Linux server, these boundaries can limit how far an attacker can move after compromising one website.
For OpenLiteSpeed hosting, directory permissions should be considered alongside virtual host configuration, PHP execution, CyberPanel user management, resource limits, and application-layer security.
The objective is simple: one website should not automatically become a gateway to every other website on the server.
A properly isolated hosting environment does not eliminate every security risk, but it can significantly reduce unnecessary access and limit the potential impact of a compromised application.
