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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
