Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58644
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain anderiasch.de from 81.169.138.148 cause and error)
Message-ID: <4F55CB27.7070305@anderiasch.de>
Date: Tue, 06 Mar 2012 09:30:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Adam Jon Richardson <adamjonr@gmail.com>
CC: internals@lists.php.net
References: <CAJzDObekVt_F6JZP-B-YCs0khvfcSDW1PNeC6Bf5LUk=xPqVAQ@mail.gmail.com>
In-Reply-To: <CAJzDObekVt_F6JZP-B-YCs0khvfcSDW1PNeC6Bf5LUk=xPqVAQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Providing sandboxed versions of include and require
 language constructs
From: florian@anderiasch.de (Florian Anderiasch)

Hi,
On 03/06/2012 08:34 AM, Adam Jon Richardson wrote:
[...]
> 1) Internal functions seen as universally safe would by default be allowed
> (e.g, str_replace(), array_pop(), etc.)
> 2) Unsafe internal functions would have to be explicitly declared (e.g.,
> file(), stream_*, etc.)
> 3) Any includes or requires within the sandboxed code would be forced to
> meet the same restrictions. (tricky)
> 4) Code containing unsafe functions not included in the whitelist would
> raise an error.
[...]
> Thoughts?

Isn't that basically what all template engines tried to solve before
with giving you a defined subset of tokens that are more or less
directly converted to php code? The benefit I see is that plugin
developers wouldn't need to learn a new DSL (domain-specific language),
but use PHP code. Just that it's not PHP if you disable 90% of the
functions available.

While the idea is certainly not bad, I'm not sure you could write
sensible plugins for applications with only a few string functions at
hand. My gut instinct tells me you'll run into something like "I wish I
had this dir() to get the files in this directory" more sooner than
later. Last plugin (for Drupal) I wrote for example hooked into the File
API and saves/retrieves uploads to/from MogileFS. So that's file access
AND network access, and those would quite probably the first on the list
to be blacklisted. And if you only blacklist a few, disable_functions
might be enough.

To sum it up, to solve this problem I'd be more thinking about creating
a specific DSL (like puppet) to fill my needs and not try to make people
write some sort of 50%-PHP with constant lookup which functions are
allowed and which are not.

Greetings,
Florian