php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #38622 Proposed new security scheme for shared hosting (safe mode substitute)
Submitted: 2006-08-28 05:39 UTC Modified: 2018-05-05 18:25 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:1 of 2 (50.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: php at troy dot rollo dot name Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 6CVS-2006-08-28 (CVS) OS: UNIX/Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: php at troy dot rollo dot name
New email:
PHP Version: OS:

 

 [2006-08-28 05:39 UTC] 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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-05 18:25 UTC] requinix@php.net
-Status: Open +Status: Not a bug -Package: Feature/Change Request +Package: *General Issues
 [2018-05-05 18:25 UTC] requinix@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 01:01:28 2024 UTC