> > > > Introducing a sandbox API for security also opens up a can of worms > > for the security policy. Right now we are assuming an attacker > > model of a remote attacker, and that the code running on your > > server is trusted. But that would change when an official sandbox > > API is introduced. > > > > Kind regards > > Niels > > > Hey Niels, > > I find this assertion kind of scary from a shared hosting perspective > or even from a 3v4l kind of perspective. How do these services > protect themselves if php is inherently insecure? > > — Rob
So I was thinking about this a bit more and I thought, what if instead of adding a sandbox as a feature of PHP, what if PHP *was* the sandbox. So consider this: What if the PHP engine added a C API that lets C/C++ programs not only spin up and run PHP, but those C/C++ programs could also control and monitor the execution of the PHP environment from the outside. That would essentially make every instance of PHP a sandbox. But now, we would be able to control, monitor, and override certain behavior from the outside while script execution runs. This gives us a foundation to do two different things. ** Thing 1: A PHP extension for the PHP C API ** PHP's C API could then be controlled by a PHP script by using a PHP extension that uses the PHP API. This would allow PHP scripts to spin up and control instances of PHP, running in their own execution context. This meets the use case of Unit Testing scripts and secure execution of third party plugins by PHP applications. ** Thing 2: C/C++ programs could use PHP as a library ** With a comprehensive C API to PHP, we could build C/C++ applications that can use PHP scripts as a plugin. Let's consider a use case for a social media site or ecommerce platform that is high traffic and written in PHP. What if we moved the front controller logic to a C application that was built as an Nginx module? Nginx Modules are statically linked, so now our front controller, written in C, would be native inside Nginx, usable in location blocks. Thanks to the C API for PHP, our front-controller-as-Nginx-plugin can directly invoke parts of the PHP application as needed, and inject resources directly into the PHP environment. This isn't the same as a Fast CGI pass. This moves the routing, session setup, and other redundant code into a native C application that's actually part of the whole app. So you could route requests, setup sessions, and serve cached pages as fast as Nginx can process a request (about 1ms). When the C land front controller needs to invoke PHP, it invokes PHP through PHP's C API that lets the front controller pass data directly into the PHP instance. For example, the C front controller application can register a database class inside the PHP environment that's already primed with an open database connection (saves 20ms). Because the running PHP application is actually talking back and forth with the C land front controller, the C land front controller can remember things (including session details) for faster responses. This hybrid approach gives you the best of both worlds: Very fast response times for most requests because the front controller and sessions and other resources are handled in native C land, inside the web server, while also giving you the flexibility, ease of use, and rapid prototyping of PHP.
