lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Finally if all variables are purely local and you enforce Lua to behave as a functional language, all Lua scripts will have to pass many input and output parameters explicitly. Calling functions will be much slower. The Lua solution where the environment is implicitly passed as a single implicit parameter to every function call is MUCH faster and more efficient (no need to copy input/output values). and Lua scripts are much simpler (they benefit of the fundamental concept of "closures", which makes Lua scripts really easy to use.

Enforcing the "\" rule is the same as dropping the concept of closures completely. Lua will be much less usable, and scripts will be considerably slower and more complicate to program with tons of additional parameters and additional return values.

With it, you're not at all programming in the same language. You've created a new tricky language, which will have even more bugs (how many input parameters must we pass, and in which order), will be slower, will generate larger bytecodes (coping with all input/output values and transfering them from one function to every subfunction calls), and will also be unsafe (if "\" allows bypassing the functional isolation).




Le sam. 16 mai 2020 à 09:01, Philippe Verdy <verdyp@gmail.com> a écrit :
Also the proposed "solution", if it becomes implemented by default, would create a severe security issue: if the "\" syntax is used to uinconditionally give access to the parent environment, it will become a way to bypass the sandboxing protection offered by the write accessor defined in the local environment. A user script could then be allowed to read or write protected values that are part of the parent environment chain.

I consider this proposed extension really unsafe, not acceptable in lot of cases. Notably when local scripts are written by external users of a shared service, because users could write scripts that could inspect and modify the caller environment and then inspect the state of all other concurrent scripts on the service, or could easily access to protected passwords (hidden by the sandboxing local environment, or could have access to restricted functions (e.g. using network services in the parent environment to send spam mails, even though these services were isolated and not linked into the local environment which normally offers no way to access other services).

Once again the correct solution for local Lua scripts that want to make sure they are properly isolated and don't affect the behavior other scripts, is to start the script with a simple "require('no global')" which will set the simple accessor into the local environemnt to block the chain of lookups. Then scripts can define their own "global" environment, and create subenvironement where needed for subfunctions in the same script (each function that needs it can also start by the same "require()" statement).

We don't need the "\" tricky syntax at all.

Le ven. 15 mai 2020 à 15:14, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> a écrit :
See this thread: http://lua-users.org/lists/lua-l/2018-07/msg00422.html

For a patch to play with global decoration of variables, see
http://lua-users.org/lists/lua-l/2018-07/msg00430.html
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org