---
title: "Platform isolation overview"
date: "2015-10-08"
category: "platform"
slug: "platform-isolation-overview"
---

## Overview

The ApisCP platform uses multiple security subsystems and user roles to maximize throughput while keeping your account secure. This article explains how account isolation and partitioning works.

## Filesystem Layers

Every account is composed of several filesystem layers. Lower layers are read-only and provide the base environment for services. The top-most layer is a read-write **client layer** where all your files reside.

When a file exists on multiple layers, the top-most (read-write) layer takes precedence. Each account's **client layer** is completely separate from other accounts.

/home/virtual/site180/shadow/.aufs.xino
/home/virtual/site180/shadow=rw
/home/virtual/FILESYSTEMTEMPLATE/siteinfo=ro
/home/virtual/FILESYSTEMTEMPLATE/ssh=ro

**Figure:** A sample filesystem layout. "ro" is read-only. "rw" is read-write. FILESYSTEMTEMPLATE layers are shared by all accounts. ".aufs.xino" is a system file used by aufs for inode recycling/translation.

### Benefits

- Updates and new features can be deployed instantly through shared layers
- You can modify system files without affecting other users or server integrity
- In the event of an [[handling-a-hijacked-account]], damage is limited to the account's read-write layer, isolated from system layers

## Pivot Roots

Every process (except PHP) operates within a **pivot root**: a separate filesystem environment tailored to your account. Depending on which services are enabled (terminal, Ruby, Java), different layers are incorporated into your pivot root.

### Benefits

A pivot root provides a personalized, self-contained environment. As you add, remove, and modify files, every application spawned from your account inherits those changes. Your account remains consistent and independent from other accounts, similar to a virtual private server. In the event of an [[handling-a-hijacked-account]], damage is confined to your account's read-write layer.

## PHP

PHP is the exception. It operates as an interpreted language embedded within the HTTP server (ISAPI module) for performance. HTTP processes have access to the full filesystem (system layers + account pivot roots), and the PHP interpreter is loaded into each HTTP process directly. This eliminates the need for separate PHP processes, providing a **memory-efficient implementation with the highest throughput**.

### PHP Security

Since PHP operates outside of a pivot root, additional restrictions ensure it can only access your files:

- **Directory restrictions** prevent PHP from accessing files outside your [[open_basedir-restriction-messages]]
- **ACL restrictions** block access to shell commands (`rm`, `mv`, `cp`) via [access control lists](https://wiki.archlinux.org/index.php/Access_Control_Lists)

Use the equivalent PHP functions instead:

| Shell Command | PHP Equivalent |
|---------------|----------------|
| mv | [rename](http://php.net/rename)(oldname, newname) |
| cp | [copy](http://php.net/copy)(src, dest) |
| rm | [unlink](http://php.net/unlink)(file) |
| rmdir | [rmdir](http://php.net/rmdir)(dir) |
| touch | [touch](http://php.net/touch)(file) |

## See Also

- [[open_basedir-restriction-messages]] (PHP)
