[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: tostring userdata
- From: Sean Conner <sean@...>
- Date: Tue, 2 Jul 2019 21:03:29 -0400
It was thus said that the Great Patrick Donnelly once stated:
> On Sun, Jun 30, 2019, 9:42 AM Andrew Gierth <firstname.lastname@example.org>
> > >>>>> "Tom" == Tom Sutcliffe <email@example.com> writes:
> > Tom> I've tracked this down to the fact that the test - not the
> > Tom> production code :) - was relying on the tostring representation of
> > Tom> a full userdata 0xABCD being the same as the lightuserdata
> > Tom> representation of the same pointer - they were both "userdata:
> > Tom> 0x1234" on 5.3
> > er... no?
> > In 5.3, the tostring representation of something that's not a number,
> > string, boolean or nil and which has no __tostring metamethod is:
> > lua_pushfstring(L, "%s: %p", kind, lua_topointer(L, idx));
> > where "kind" is the value of the __name metafield if it exists and is a
> > string, and is the luaL_typename of the original value otherwise.
> While we are on this subject, giving Lua scripts access to the pointer
> address to something in memory is a needless footstool to breaking out of a
> sandbox and potentially taking over an application.
I'd like to see a proof-of-concept before I worry about that. I mean, I
can always do
x = 0xcbc5c0
which *is* a valid address on a running instance of Lua on my system. Or
0xb7d7f000 or 0x00cbe040 or any number of other values.
-spc (And no, loading a special C module to exploit this won't cut it)