Skip to content 
CageFS restricts the file system view individual users in shared hosting. Processes running within the intended context are assigned their own environment instead of using the full host view. In this way, the CloudLinux component makes it more difficult to snoop on other customer accounts, provided that services and permissions are configured appropriately. It does not replace resource limits or the security measures for applications and the host. It is therefore crucial for operators to verify the actual execution path; customers can typically only assess their own context.
Why Hosting Accounts Need Isolation
With shared hosting, multiple customers run their websites on the same server. If a script in Account A is compromised, it may attempt to gather information about the environment and access files in other accounts. This may include configuration files containing login credentials or personal data. The separation of accounts is intended to make such access more difficult, even though the infrastructure is shared.
These include Visibility and Access Rights Different issues. A directory name may be visible even though file permissions prevent its contents from being read. Conversely, a restricted view alone is not a substitute for carefully configured permissions: Anything that is accessible within the environment must still be adequately protected.
CageFS adds a user-specific file system environment to the permissions. A process running in the designated context does not simply have the same view of the host as an administrator. This is intended to prevent a script running under Account A from easily exploring directories belonging to other accounts. Which areas are actually visible depends on the configuration.
For operators, this is an additional Separating layer, no guarantee against any impact on other customers. Errors in shared services, overly broad permissions, or incomplete service integration can affect the level of protection. Therefore, isolation must be verified where customer programs are actually running, and not merely based on a setting in the administration console.
For hosting customers, this distinction is also important: The fact that a user’s own application cannot see a third-party directory merely describes its specific execution context. It does not prove the configuration of all services or the protection of all other accounts. The provider remains responsible for overall setup and control.
How CageFS Organizes the File System View
CageFS provides users with their own view of the file system. It is based on the Skeleton: a template containing files and directories that are made available for the respective environment. The necessary components are included; the user's own home directory is also integrated into their environment. The visible directory tree is therefore not simply an unmodified copy of the host view.
This integration can be illustrated using an example: An administrator installs a program on the host, but a client process cannot find it in its environment. This is not necessarily an installation error. The program may be present on the host without being available to the client in the skeleton or through the designated integrations.
Conversely, every additional file made available expands the environment that a process can see. The same applies to a mounted directory. Administrators must therefore weigh the functional requirements against the additional visibility: An application may need a specific tool and its dependencies, but not necessarily an entire directory on the host.
The Mount Configuration It helps determine which parts of the file system appear in the environment. However, it does not solely determine whether a process is allowed to read, modify, or execute a visible file. Ownership and permissions, among other factors, remain relevant in this regard. A visible path is therefore not synonymous with permitted write access.
Your home directory remains particularly important for day-to-day hosting: that’s where the files for each account are typically stored. This integration allows access within the intended context, while the rest of the view is restricted. However, whether a specific application can access all the necessary files depends on its configuration and the paths that are actually available.
CageFS, LVE, and Common Risks
CageFS and LVE address different problems. CageFS shapes a user's view of the file system and execution context; LVE is used to monitor and limit resources such as CPU, memory, and I/O. A process with restricted file system visibility may still consume resources. Conversely, a resource limit alone does not prevent access to incorrectly shared files.
A hosting control panel serves another purpose: Among other things, it manages accounts and can integrate CloudLinux components. However, simply installing a panel does not guarantee that every web process, every shell, and every scheduled task will run within the intended CageFS context. Administrators must verify the appropriate integration for their specific platform.
CageFS does not provide a separate virtual machine for each account. The accounts continue to use a shared kernel and may depend on jointly operated services. A vulnerability or misconfiguration in these shared components therefore remains part of the threat model. File system isolation reduces part of the visible environment, but does not replace host security and maintenance.
Risks remain even within a properly isolated account. For example, a vulnerable application may expose its own data; stolen credentials may grant an attacker access within the affected account. CageFS does not correct insecure application code or overly permissive permissions on files accessible within that account.
For a robust security strategy, these layers must therefore work together: accounts and services must be properly integrated, file permissions must be controlled, resource limits must be set appropriately, and applications must be kept up to date. The level of protection this provides depends on the actual configuration and the services being run. The name of a single component does not replace this assessment.
Consider Accounts and Websites Separately
Having two customer accounts on the same server is different from having two websites within a single account. CageFS provides a user-specific environment, thereby limiting an account's view of the file system. However, this does not mean that every website within that account is assigned its own file system boundary.
If an agency runs multiple projects under the same hosting account, their applications may access files from other projects, depending on the execution context and permissions. If an attacker gains access to a website through a vulnerable plugin, it is therefore necessary to check which configuration files and login credentials are accessible under that account. The fact that it is separated from a second customer account does not answer this question.
For a finer Website Separation CloudLinux documents additional domain-based file system isolation with CloudLinux Isolates. Whether this feature is available depends on the specific product availability, version, and control panel integration. Check these requirements for your own hosting stack instead of assuming that domains are isolated based solely on CageFS activation.
Domain-specific LVE limits are also a separate feature with their own requirements. Therefore, an additional filesystem limit does not automatically mean that CPU or memory are limited separately for each domain. The article about CloudLinux Site Isolation clarifies the difference between the account level and the website level; the requirements of the product variant being used remain decisive for setup.
When planning, it’s a good idea to start by taking stock: Which sites share an account, which files do they need to share, and which access credentials should remain separate? This will help determine whether separate accounts or domain-based isolation are a better fit for your operational model. Both options require an analysis of the actual usage patterns.
Check Pilot and CageFS Status
Before launching a pilot, as the operator, you should verify that the operating system version being used is supported, that the required packages and license are available, and that the control panel is properly integrated. The fact that a control panel is documented as supported does not mean that every feature will work the same way in every combination. Also note which applications and tools the selected test accounts require.
Start with explicitly authorized test accounts and a manageable selection of typical applications. Check their home directories, required programs, and relevant execution paths before adding more accounts. For the initial setup, you can use the mode in which CageFS is disabled by default and individual accounts are enabled; alternatively, there is a mode in which CageFS is enabled by default with exceptions.
The following read commands are intended for authorized administrators on a system with CageFS installed. TESTBENUTZER Replace this with an existing account that has been approved for testing. The required permissions and the specific output depend on the system; the commands do not change any configuration.
The first command displays the global CageFS status, and the second displays the Operating Mode. The third one checks the status of the selected account. Mode and account status must be considered together: A mode that is enabled by default may have exceptions, while in the other mode, individual accounts are explicitly included.
A positive status message does not necessarily prove that every service is actually running in the intended context. Therefore, document separately what the administration reports and which execution paths were verified using the test account. Only then can a decision be made as to whether the pilot can be expanded to additional accounts and which exceptions are operationally necessary.
A Comparison of Protection Strategies
The approaches differ primarily in terms of where they draw the line and who manages them. The table categorizes their protection objectives; the information on operating costs is qualitative planning guidance, not measured values. Specific requirements depend on the respective platform and its configuration.
| Approach | Primary Conservation Goal | Administrative Unit | Shared Dependencies | Operating expenses | Open-ended exam question |
|---|---|---|---|---|---|
| Linux File Permissions | Control File Access Based on Permissions | Users and Groups | Permissions and Process Context Used | Manage Permissions and Groups | Which processes are allowed to open which files? |
| CageFS | Restrict User-Specific File System View | Hosting account or user | Host, Services, Mounts, and Permissions | Maintain Skeleton and Service Integration | Are the relevant services running in the Cage? |
| CageFS plus LVE | Restrict file system visibility and limit resources | User or LVE | CageFS and LVE Configuration and Service Integration | Set and check resource limits | Are isolation and execution limits in effect? |
| CloudLinux Isolates | Additional domain-based file system isolation | Domain within an account | Product variant, version, and panel integration | Check Availability and Site Assignment | Which domains are actually included? |
| VM or separate server | Provide your own system environment or your own hardware | VM or Server | For a VM, specifically a virtualization platform; for both, their own system administration | Operate and update your own system | Who manages and secures the operating system and services? |
File permissions and restricted visibility are not interchangeable concepts: Even a visible path may not be readable, and a shared path must be appropriately secured. CageFS supplements these permissions with a controlled environment. LVE, on the other hand, addresses resource consumption; for joint use, both layers must be properly configured.
A own VM shifts the administrative boundary relative to a user-specific environment: The guest system must be maintained independently and remains dependent on the virtualization platform. A separate server further alters the shared infrastructure. Which option is appropriate depends on the threat model, the required permissions, and the available operational resources.
A blanket security ranking would therefore be misleading. For a comparison of other mechanisms and their respective areas of application, the overview of Process Isolation in Hosting. The key factor is then a detailed review: Which restrictions are intended to prevent which types of access, which services violate them, and who monitors the configuration?
Testing Execution Paths in a Controlled Manner
An activated account does not necessarily mean that every associated process will actually start in CageFS. The decisive factor is the respective Execution Path: SSH login, web servers, and scheduled tasks can use different integrations. Administrators must therefore check for each relevant service how it maps processes to the account and its environment.
For a controlled test, the operator sets up an authorized test account and uses only its own, explicitly approved test files. A file within the designated environment can demonstrate whether the expected access works; a file prepared separately outside the designated view is used to test the scope of access. Third-party customer directories are not suitable test material for this purpose.
First, use SSH to verify which environment the test account is actually assigned to and whether the intended test files are accessible as expected. Repeat the test using a web application set up for this purpose and a scheduled task. The results may vary if services are integrated differently or run under a different user context.
For each attempt, record the service, account, path, and result. A denied access request only demonstrates the observed boundary in this specific context; it does not prove either the correct isolation of all services or the security of the entire host. Conversely, an unexpectedly successful access attempt should be investigated before additional accounts are put into operation.
As a hosting customer, you can check your own execution context and shared files. You generally cannot independently verify global CageFS settings, other accounts, or the integration of all services. The provider is responsible for these matters; if you notice any issues, describe the affected service and the specific path to the provider.
Missing Tools and Skeleton Maintenance
If a tool is installed on the host but cannot be found in the customer account, first check the execution context. A command run via SSH may not use the same environment as a web application or a scheduled task. Next, check the search path and the specific error message before assuming that a package is missing.
The operator then examines the Skeleton and the mount configuration. The skeleton helps determine which files and directories are made available in CageFS. A program may therefore exist on the host but still be missing from the user-specific environment; required libraries and other dependencies must also be taken into account during provisioning.
The practical solution is not to mount large host directories as a precaution. Doing so might make more files visible than are necessary for the task. Instead, the administrator should use the manufacturer's documentation to select the required program files and dependencies and then test whether the tool works in the intended service context.
To Skeleton Maintenance It is also important to take into account changes to system packages and the Control Panel. CloudLinux documents a periodic update; after certain changes, a forced update may be necessary. It may also be required after an Apache rebuild. This does not mean that the same manual command must be executed after every update.
Plan the update according to the platform in use, and then test the affected applications and tools. If an application was working previously but fails after a change, the timing of the package change, the affected service, and the exact error message will help you narrow down the issue. This allows you to distinguish between a deployment issue and an application error.
Operate Safely and Make Informed Decisions
When making an operational decision, it is not enough to simply consider whether CageFS is generally available. The operator must know which accounts and services need to be protected, which programs they require, and who is responsible for integration and maintenance. The restricted file system view complements other security measures; it does not replace secure applications or the protection of access credentials.
The following deserve special attention: common areas and additional mounts. CloudLinux describes for /dev/shm A shared integration and an isolation option per user. Which option actually applies must be determined based on the specific configuration. Additional mounts should only provide what applications need, because they can expand the visible environment.
An error when entering CageFS is also a security concern. Starting with CageFS 7.2.0-1, CloudLinux documents an option that can be used to prevent processes from running in the event of such an error. Check the installed version and the actual setting instead of assuming how this option will behave in a specific hosting environment based solely on its existence.
Changes to Skeleton, mounts, or account assignments belong in a coordinated Maintenance Procedures. Take into account any potential remounts, affected applications, and a maintenance window; also document how the change can be reversed in case of problems. Afterward, the relevant execution paths and required tools should be verified again using the designated test accounts.
For customers, the key question is what level of isolation the provider actually implements and how it verifies it. Providers, on the other hand, must balance security needs with ongoing effort: An environment that is too permissive can weaken isolation, while one that is too restrictive can hinder necessary applications. Both require careful configuration and regular review.
Sources and Current State of Knowledge
Status of the research:
This information is based on the provided sections and the list of sources as of the research date of November 4, 2026. Product availability, version, and panel integration should be verified for the respective platform.
https://docs.cloudlinux.com/cloudlinuxos/cloudlinux_os_components/
https://docs.cloudlinux.com/cloudlinuxos/limits/
https://docs.cloudlinux.com/cloudlinuxos/isolates/
https://docs.cloudlinux.com/cloudlinuxos/command-line_tools/
https://docs.cloudlinux.com/cloudlinuxos/control_panel_integration/
