Re: Protect global table from any changes

[Flyer31 Test <flyer31@...>]

PS: in my last post it should say "somehow at least prepared/planned
for future" (not "not for future").

And my last paragraph proposal is somehow rubbish ... so if you would
replace "unfreeze" by an empty function and then freeze for the
sandboxing time ... after sandbox is finished how could you then
unfreeze _G for your further Lua code? This would not work ... .

So this would reduce to the application, where you want to freeze _G
completelly, let's say after some setup functionality has been
completed...  .  This really sounds very restrictive and I am not sure
about the number of Lua applications who would like it. (But thinking
about this a bit more, I definitely would liike this for many
applications...).

On Fri, Jan 21, 2022 at 7:00 AM Flyer31 Test <flyer31@googlemail.com> wrote:
>
> If you want to implement read-only data, you have to distinguish
> mainly also between "pre-defined read-only" or "run-time read-only".
>
> Pre-defined read-only I think is somehow at least prepared / planned
> not for future Lua versions by introduction of the variable qualifier
> const. As I see it, this is not really used yet (it can be very useful
> mainly in restricted RAM controller applications, as then mainly e. g.
> literal strings can possibly "sleep in ROM" in some furture ... just
> large systems as already PCs usually anyway always use "RAM-only"
> approach for Data+Code (so called von-Neumann-architecture in contrast
> to the typical Microcontrollers with separated RAM and ROM and RISC
> instruction set, e. g. ARM,...).
>
> But as I understand you, you would like to have run-time read only. So
> a method to freeze e. g. _G during runtime and then somehow perhaps
> another command to "unfreeze" it again at some later time. So that
> sandboxing _G would somehow work quite easily by just re-aligning this
> unfreeze function to an empty function and then freeze _G. Just then
> of course inside the sandbox it will be not allowed to construct any
> "new function" sand castles e.. g. ... so the fun factor in such a
> sand box might decrease significantly :).
>
>
>
> On Thu, Jan 20, 2022 at 10:19 PM Petri Häkkinen <petrih3@gmail.com> wrote:
> >
> >
> > On 20. Jan 2022, at 22.38, Coda Highland <chighland@gmail.com> wrote:
> >
> > 
> > On Thu, Jan 20, 2022 at 1:24 PM Petri Häkkinen <petrih3@gmail.com> wrote:
> >>
> >> Luau (Roblox’s custom Lua implementation) does it right by allowing flagging any table as read only. Trying to modify a read only table raises an error.
> >>
> >> Since the branches needed to implement this inside the VM are very coherent, the performance overhead is pretty small. I think it would make sense for Lua to support this as well.
> >>
> >> Petri
> >
> >
> > VM modifications aren't necessary from a semantic perspective. As has been mentioned: You can already implement read-only tables and have been able to for quite a long time. You have also been able to make proxies for a very long time, allowing each script's environment to "inherit from" the base environment without permitting modifications back to it. Doing it this way has pretty low memory overhead (you aren't duplicating the entire environment per script) and the performance isn't THAT much worse in practice.
> >
> > Implementing it into the VM would be an optimization, not something necessary for functionality. This is why we have a wiki page for useful patches that some people might find valuable. Vanilla Lua is primarily focused on keeping a streamlined, elegant implementation, and new features are typically introduced in response to an obvious need that can't be handled in Lua code.
> >
> > /s/ Adam
> >
> >
> > Yeah I know. But there are many other redundant features in Lua and pretty much any language. For example, for, while, * and closures. Just a few random examples.
> >
> > It’s about finding the right balance; minimalism is a good principle but going too far with it is not pragmatic. In my opinion, the usefulness of native read only tables more than compensates the small increase in complexity and performance cost to the VM.
> >
> > Petri