Re: ENFORCE_SAFE_MODE

Stanislav Malyshev wrote: > Why safe_mode is needed is that all processes run by webserver (either > threaded or not) are run under webserver user ID, and there's no way (at > least until Apache 2.0 arrives) to change it. The same with threads in a common process - they also share a common UID, a common cwd, a common root dir. > That's why we have safe_mode > - to emulate behaviour that would be if the script was run under user ID > of it's owner, and then adding some restrictions that might be needed > because web-user access is lower-grade one from shell-access. Actually safe_mode does more than a CGI PHP under a different uid would do. For example, in safe_mode you cannot even touch foreign files and directories, even if the file permissions of the simulated uid would allow for that. It also restricts the binaries you can call. In some respect it is a bit like running CGI PHP in a chrooted environment (except that it does not use the virtual filesystem functions to enforce a path prefix to be prepended to every filename and deleting any .. references out of that prefixed tree). > KK>> context in a way we require, we would be using CGI php and > KK>> have no need for safe_mode, because we would have no need > KK>> for mod_php. For example, the operating system could provide > > Huh? CGI PHP is slow. Like _slooooooow_. It's new process every time. CGI PHP in a rlimited chrooted environment is a secure concept to run PHP. If it were not that slow, it would not be necessary to have safe_mode. Why is CGI PHP slow? Because it creates process contexts and loads them up for every request. So what you do is create mod_php, and reuse the old process context with each request (you run as part of the httpd process context). That's why mod_php is so much faster. This is the same reason as was used for the invention of threads, where you thread switch within the same process context, and that is faster than switching between different processes. The problems you experience are similar, too, because of the shared or reused process context: If you chrooted, chdired or setuided yourself in a threaded model, you would fsck up all other threads as these are global variables. If you chrooted yourself in mod_php, you would not be able to reuse the old process context for the next request as there is no graceful way out of the chroot after you have finished the request. In both cases you end up simulating OS functionality in userspace because the security model offered by the OS is not sufficient. safe_mode and threaded case are really two facets of the same case. safe_mode multiplexes a process context in time, threads do it concurrently. The code to handle this can be folded into each other, if done right. And unless the OSes come up with sufficient security models for our problems we cannot spare ourselves the work to duplicate OS functionality in userspace, despite the fact that this is clearly the wrong architectural model to chose. Kristian -- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/