use current frame scope for permission filter function calls

Question

proposed fix for follow-up issue/regression after implementing #7113 for #6874

should be reviewed by someone having the big-picture of the code

该提问来源于开源项目：Icinga/icinga2

Answer 1

I think technically the functions would be able to use locals as every function-wrapper creates a locals dict in the frame dedicated to the function-run on each execution of function anyway (within function wrapper encapsulated in a Callback / std::function).

The permissionFrame (or the frame passed to the DoEvaluate) is anyway not the frame the function Executes in. There is one more frame created in VMOps::FunctionCall -> Function::InvokeThis for calling the call Method/Function of Function (having no Locals and the Function Object as Self) and within call-method-function the Function to execute itself is taken from that frame and again Function::InvokeThis is called, again creating a ScriptFrame (having no Locals but setting Self to the Value of Arg0 wich is the one we specify in FilterUtility::CheckPermission). The Locals are then populated by the wrapper around the parsed function (which initializes the Locals with ClosedVars and Arguments for each execution). That means it is effectively no difference for the permissons check function.

The thing that locals assignments are never allowed in sanboxed frames is more a shortcoming or a bug instead of expected behaviour from my point of view. (It wouldn't change any persistent state if the assignment affects only locals as the locals are thrown away at end of function execution...)