Re: Protect global table from any changes

[Flyer31 Test <flyer31@...>]

But then Lua will "sort of crash" in sandbox (of course with error
message, but anyway crash) ... and if this crash is not restricted to
sandbox but crashes also any further scripts which invoked this
sandbox, this typically sounds quite obstructive / dangerous.

... but generally I also somehow like this idea to have the possibilty
to set read access flag for any table...

In this example Luau which you cited, who is this done then if you
want to switch back a table later to "normal mode" / "write mode" (so
"unfreeze") - does this work on Luau user level or this this
impossible? (and does it work from Luau C interface, or impossible?)



On Fri, Jan 21, 2022 at 9:12 AM Petri Häkkinen <petrih3@gmail.com> wrote:
>
>
> > On 21. Jan 2022, at 8.09, Flyer31 Test <flyer31@googlemail.com> wrote:
> >
> > sorry, another PPS: What would you then ask Lua to do, if somebody
> > would try to modify _G inside sandbox or in later code? Should Lua
> > then terminate with an error message, or just ignore this modification
> > approach? (I think both possibilities would be quite bad, especially
> > also for sandboxing...).
>
> This is not only about _G. In a sandboxed app you need to protect all the module tables too and potentially any tables you pass between sandbox and privileged environments. Proxying everything has a major implementation & performance cost in many applications and it’s far from being elegant.
>
> Luau C API has a function for setting a read only flag per table. Typically in a sandboxed app you protect _G and all the module tables after startup.
>
> Trying to modify a read only table raises a Lua runtime error so it behaves identically for example to “trying to index a nil value” error.
>
> Petri
>