Okra Host utilizes a unique platform that consists of multiple security subsystems and user roles to yield optimal throughput and keep your account secure. This article will explain how account partitioning works.<\/p>\n
Every account is comprised of several layers of files. These layers are read-only and provide a basic environment for services to operate. The top-most layer is\u00a0a read-write client layer<\/strong>. Any file created within the\u00a0pivot root<\/strong> resides on this top-most layer. Any file in the read-only layer is copied up to the client layer<\/strong>. If a duplicate file exists on multiple layers, the top-most layer is used. It will always be the read-write\u00a0client layer<\/strong>. Every client layer<\/strong> is separate from andere<\/em> client layers<\/strong> ensuring integrity.<\/p>\n By keeping multiple layers shared between accounts, updates can be easily deployed, as well as new features. Separate layers also allow the primary user to manipulate system files without affecting other users or server integrity. In the event of an account hack<\/a>, damage is limited only to the account read-write layer, which is isolated from system layers.<\/p>\n Every process, except for PHP, operates within a pivot root<\/strong>. A pivot root<\/strong> is a separate filesystem with a separate environment from the main server that provides an environment in which applications can run. Each account has a pivot root<\/strong> tailored to that account. Depending upon the services enabled (terminal, Ruby, Java), different layers will be incorporated into the pivot root<\/strong>.<\/p>\n A pivot root provides a personalized experience for you comprised of your files. As you add, remove, and modify\u00a0it, every application spawned from your account will inherit these changes. This ensures that your account will remain consistent and independent from its neighbors, like a virtual private server,\u00a0as it ages. In the event of an account hack<\/a>, damage is limited only to the account read-write layer, which is isolated from other accounts.<\/p>\n PHP is the exception to the rule. PHP operates as an interpreted language embedded within the HTTP server (ISAPI module) for performance. HTTP processes have access to the entire filesystem, which is a composition of the system service filesystem + account pivot roots<\/strong>.\u00a0As HTTP processes spin-up and spin-down to accommodate server loads, the PHP interpreter is copied into each process. Consequently, only the HTTP process is necessary to serve a page, unlike CGI implementations that spawn a\u00a0separate PHP process<\/em> to handle runtime compilation. CGI implementations leave behind dormant processes with compiled code in-memory anticipating future requests. ISAPI, on the otherhand, immediately releases the memory occupied by code anticipating a new request. This provides a memory-efficient implementation for PHP and the highest throughput<\/strong>.<\/p>\n Since PHP requests operate outside of a pivot root<\/strong>, special care is necessary to ensure PHP can only access your files and run trusted code. A separate set of directory restrictions are in place restricting PHP from accessing files outside your absolute root<\/a>. A second pass restricts access to binaries non-conducive to PHP, including \/home\/virtual\/site180\/shadow\/.aufs.xino\r\n\/home\/virtual\/site180\/shadow=rw\r\n\/home\/virtual\/FILESYSTEMTEMPLATE\/siteinfo=ro\r\n\/home\/virtual\/FILESYSTEMTEMPLATE\/ssh=ro<\/pre>\n
Benefits<\/h3>\n
Pivot Roots<\/h2>\n
Benefits<\/h3>\n
PHP<\/h2>\n
PHP Security<\/h3>\n
rm<\/code>, mv<\/code>, und cp<\/code> via access control lists<\/a>. A table below provides the PHP functions that provide similar functionality to the respective Linux commands:<\/p>\n