Description:
------------
Now that "safe mode" is to be thrown out, it would be nice 
to have an alternative mechanism for providing some sort 
of security in a shared hosting environment.

I started with the basic idea that only information that 
could safely published on a newsgroup should be made 
accessible directly to the user that the web server runs 
as. Starting from this base point, I then considered what 
a PHP script would need access to that it would no longer 
have.

The first obviously missing thing would be database 
passwords. Ideally these should be made available only to 
scripts running on the virtual host authorised to use 
them. When the web server is starting up it would need to 
access a file that is specified in the virtual host's 
section of the server configuration file to read the 
passwords before forking off children and setting their 
user IDs to the running user ID. It could then make these 
available to PHP scripts as a variable only when the 
script is running on that virtual host.

For example:

<VirtualHost 192.168.0.1>
  ServerName www.virtualhost.example.com
  ...
  
php_privatefile /var/virtuals/virtualhost.example.com/privates
  ...
</VirtualHost>

The referenced file would include various settings:

  enckey=418f8ae56710cb
  dbpass=shh-its-a-secret

The HTTP server reads the file at startup and keeps the 
data. The PHP script running on the virtual host could get 
access to these values by means of an array:

  $dbpass = $PRIVATES['dbpass'];

The next thing is access to files. On the assumption that 
direct file accesses of this kind ought to be rare, it 
seems reasonable to allow calling an external program to 
assist with this. This could be handled by providing for 
an ACL file, '.phpacl' in any directory. If a file access 
fails with "permission denied", PHP could look in the 
directory and each parent for the '.phpacl' file. If found 
(and PHP would have to be able to determine its existence 
without assistance even though it could not read the 
file), it would call a setuid script, passing password to 
it taken from a specially named value in the private 
settings file (say, "_aclpass"), together with information 
on the operation it needs. If the password matches the one 
in the ".phpacl" file, and the operation is permitted by 
the ACLs in it, the setuid script changes to the user ID 
of that file and attempts the operation itself, passing 
the result back to the caller. Where the operation is 
an "open", it could pass the resulting file descriptor 
back via a UNIX domain socket (passed as file descriptor 
3, perhaps).

Without "safe mode", shared hosting becomes problematic 
because even passwords must be accessible to other hosts 
on the server and files and directories that need to be 
written to also need to be writable to other hosts on the 
server. The mechanism I have described here seeks to avoid 
that by providing a restricted mechanism whereby this 
information and files accessible only to some other user 
could be made available on a restricted basis only to the 
authorised virtual server.