Req #38622 [Opn->Nab]: Proposed new security scheme for shared hosting (safe mode substitute)

Edit report at https://bugs.php.net/bug.php?id=38622&edit=1 ID: 38622 Updated by: requinix@php.net Reported by: php at troy dot rollo dot name Summary: Proposed new security scheme for shared hosting (safe mode substitute) -Status: Open +Status: Not a bug Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: UNIX/Linux PHP Version: 6CVS-2006-08-28 (CVS) Block user comment: N Private report: N New Comment: If still relevant, which it might not be considering that shared hosting has existed for 12 years since this bug report was created and that the advent of php-fpm significantly changed how PHP can run, then the matter should be discussed on the internals mailing list. Preferably by those with direct knowledge of shared hosting practices. Previous Comments: ------------------------------------------------------------------------ [2006-08-28 05:39:31] php at troy dot rollo dot name 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. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=38622&edit=1