Every hosting account in Opterius maps to a dedicated Linux system user. Isolation is enforced at the OS level — it does not depend on application-layer controls that can be bypassed. A compromised account cannot read or write another account's files through any normal mechanism.
Linux user per account
When an account is created, Opterius:
- Creates a system user with a unique UID.
- Creates the home directory at
/home/username/with permissions0750— owner has full access, group has read and execute, others have none. - Sets the user's primary group to their own group (no shared groups between accounts).
# What account home directories look like
ls -la /home/
drwxr-x--- 8 alice alice 4096 Apr 8 10:00 alice
drwxr-x--- 6 bob bob 4096 Apr 8 10:00 bob
drwxr-x--- 9 carol carol 4096 Apr 8 10:00 carol
No other system user can read /home/alice/ — not even the bob or carol users.
Nginx access via setfacl
Nginx runs as www-data. To serve files from an account's webroot, www-data needs traverse permission on the home directory without being granted full read access.
Opterius sets a targeted ACL using setfacl:
setfacl -m u:www-data:x /home/alice
setfacl -m u:www-data:x /home/alice/domain.com
This grants www-data execute (traverse) permission only on those two directories. www-data can reach /home/alice/domain.com/public_html/ to serve files but cannot list or read any other contents of the home directory.
PHP-FPM pools run as the account user
Each account gets its own PHP-FPM pool configured to run as that account's user and group:
[alice]
user = alice
group = alice
listen = /run/php/fpm-alice.sock
When a PHP script executes for alice's site, it runs as alice. If a PHP script on alice's site is compromised — say, via an uploaded webshell — the attacker gains alice's privileges only. They cannot read /home/bob/ because the alice user has no access there, and they cannot write to server system directories because alice is an unprivileged user.
This is the primary reason PHP-FPM process isolation matters: a compromised account stays contained.
SSH isolation with Jailkit
When SSH access is enabled for an account, the shell session is chrooted to the account's home directory using Jailkit. The chroot jail contains a minimal set of binaries (bash, ls, cp, scp, etc.) copied into the jail environment.
From inside the chroot, the user sees their own home directory as /. They cannot navigate to /home/bob/ or /etc/ because those paths do not exist within their jail.
# The jail is set up during account creation
jk_init -v /home/alice basicshell editors scp sftp
jk_jailuser -m -j /home/alice alice
Jailkit SSH access must be explicitly enabled per account in Server Mode → Accounts → [account] → SSH.
What isolation prevents
| Attack scenario | Result with isolation |
|---|---|
| Webshell uploaded to account A's site | Attacker has account A's OS permissions only — cannot read account B's files |
PHP traversal attempt (../../) |
Blocked by filesystem permissions — www-data and account A's PHP pool cannot read other home dirs |
| SSH session for account A | Chrooted — cannot reach /home/, /etc/, or any path outside the jail |
| Nginx misconfiguration serving wrong account | Even if Nginx is misconfigured, file permissions prevent reading another account's private files |
What isolation does NOT prevent
Account isolation is OS-level and covers normal file access. It does not protect against:
- Root-level compromise. If an attacker gains root, all accounts are accessible.
- Shared resources such as the MySQL server — database permissions must be configured correctly at the DB level (Opterius handles this automatically per account).
- Timing side-channels or shared CPU cache attacks in multi-tenant cloud environments.
For root-level compromise protection, run scheduled Malware Scanning, keep the OS patched, and follow the practices in Security Best Practices.