On Wed, Jan 17, 2007 at 12:45:37AM +0100, Arnold Daniels wrote:
> Hi,
>
> First of all I admit I'm no PHP security expert or PHP internals expert
> or anything, so please don't flame me if I say something stupid.
>
> Wouldn't simply adding a flag to allow url's (which includes all '*://'
> streams), in functions that opens streams be enough? For example:
> fopen($file, 'r') and fopen($url, 'ru') and fopen('php://output', 'ru').
> To my opinion, using '*://' streams is an advanced feature. Developers
> who are using that, should be able to make sure no urls are opened.
> Again, just an idea.
Brilliant. The only thing that need be added is a config var to control
the default behaviour - which should be 'don't allow'.
Doesn't fix everything (eg includes), but it is a good start.
Note that: allow_url_fopen is not the same thing as that does not allow
the program to specify when it wants it.
> Last, I'm a software developer at a shared hosting company. To my
> opinion, making sure that users don't touch other people's files, does
> not belong in the PHP layer. With other apache modules you can do nasty
> thing as well. We (not me) have written a kernel patch to allow
> switching of the current processes (much like sudo) and a matching
> apache module. Since the privileges only allow the user or group to
> access the file, linux does the rest. An other solution is to start PHP
> as cgi under the correct user, but other things will never be really save.
Care to share that with the world ?
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
