Req #80017 [NEW]: Feature request: extend eval() with function/class/variable permission set

From: Date: Tue, 25 Aug 2020 07:00:57 +0000
Subject: Req #80017 [NEW]: Feature request: extend eval() with function/class/variable permission set
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-228747@lists.php.net to get a copy of this message
From:             alex at alex-at dot net
Operating system: 
PHP version:      Next Major Version
Package:          Program Execution
Bug Type:         Feature/Change Request
Bug description:Feature request: extend eval() with function/class/variable permission set

Description:
------------
This is a feature request. Alas, I lack the competence to implement it
myself.

The request is to basically make initially dangerous eval() really
usable to i.e. easily create user expression parsers, without requiring
pre-parsing of expression in order to check it.

The idea is to pass additional structure to eval() that specifies
explicitly allowed variables of the current scope, functions and classes
for the expression - disallowing everything else.

I.e. eval($expr, $limits = null) where $limits contains ['variables' =>
[...], 'functions' => [...], 'classes' => [...], 'operators'
=> [...],
'statements' => [...]], each option being defaulted to none (null). The
default value of $limits = null provides backwards compatibility
(everything is allowed).

Potential usage:

$userInput = '2+2*2'
$result = $eval('return '.$userInput.';', ['operators' =>
[EVAL_EXPRESSIONS], 'statements' => 'return']]);

will produce 6 as expected. 

If the user input contains something disallowed, like '2+my_func(2*2)',
it should throw some exception indicating expression is invalid. But
passing 'functions' => ['my_func'] in second argument can allow my_func
(i.e. mathematical functions like abs, exp, etc.) to work in the user
expressions.

The only remaining danger would be the invalid type returned like array
instead of integer, etc., but this would be much easier to post-check.

The things to think on is operator and statement allowance. I know this
is complex, but it may be a very handy addition to allow users to
provide expressions from interfaces without much extra hassle.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=80017&edit=1
-- 
Fix committed:                    https://bugs.php.net/fix.php?id=80017&r=fixed
Fixed in release:                 https://bugs.php.net/fix.php?id=80017&r=alreadyfixed
Need backtrace:                   https://bugs.php.net/fix.php?id=80017&r=needtrace
Need Reproduce Script:            https://bugs.php.net/fix.php?id=80017&r=needscript
Try newer version:                https://bugs.php.net/fix.php?id=80017&r=oldversion
Not developer issue:              https://bugs.php.net/fix.php?id=80017&r=support
Expected behavior:                https://bugs.php.net/fix.php?id=80017&r=notwrong
Not enough info:                  https://bugs.php.net/fix.php?id=80017&r=notenoughinfo
Submitted twice:                  https://bugs.php.net/fix.php?id=80017&r=submittedtwice
register_globals:                 https://bugs.php.net/fix.php?id=80017&r=globals
PHP version support discontinued: https://bugs.php.net/fix.php?id=80017&r=phptooold
Daylight Savings:                 https://bugs.php.net/fix.php?id=80017&r=dst
IIS Stability:                    https://bugs.php.net/fix.php?id=80017&r=isapi
Install GNU Sed:                  https://bugs.php.net/fix.php?id=80017&r=gnused
Floating point limitations:       https://bugs.php.net/fix.php?id=80017&r=float
No Zend Extensions:               https://bugs.php.net/fix.php?id=80017&r=nozend
MySQL Configuration Error:        https://bugs.php.net/fix.php?id=80017&r=mysqlcfg


Thread (2 messages)

« previous php.bugs (#228747) next »