Thread userdata shouldn't be overlooked - even though security contexts are
Roblox-specific, the thread userdata can still be used to implement a
permissions model for sandboxing, whether this is based on security contexts
(like Roblox, or like Ring 0/3), on capabilities, or maybe even something else.
I think it is worth it to document this in the sandboxing page.
For everyone's future reference:
* Every lua_State has an associated userdata pointer at the end. It's just a
pointer at the end called userdata:
void* userdata;
This pointer is never accessed or set by Luau itself, except for when
first initializing the state, where it is set to NULL.
This userdata can be set by the host after creating the thread, and is 100%
invisible to Luau code. C functions exposed by the host can access the
userdata by L->userdata, and, safe in the knowledge that it cannot be tampered
with, use it to validate the thread.
* The global_State (the VM, as opposed to just the main thread) contains a field
called cb:
lua_Callbacks cb;
The struct is currently defined as:
/* Callbacks that can be used to reconfigure behavior of the VM dynamically.
* These are shared between all coroutines.
*
* Note: interrupt is safe to set from an arbitrary thread but all other
* callbacks can only be changed when the VM is not running any code */
struct lua_Callbacks
{
/* gets called at safepoints (loop back edges, call/ret, gc) if set */
void (*interrupt)(lua_State* L, int gc);
/* gets called when an unprotected error is raised (if longjmp is
* used) */
void (*panic)(lua_State* L, int errcode);
/* gets called when L is created (LP == parent) or destroyed (LP ==
* NULL) */
void (*userthread)(lua_State* LP, lua_State* L);
/* gets called when a string is created; returned atom can be retrieved
* via tostringatom */
int16_t (*useratom)(const char* s, size_t l);
/* gets called when BREAK instruction is encountered */
void (*debugbreak)(lua_State* L, lua_Debug* ar);
/* gets called after each instruction in single step mode */
void (*debugstep)(lua_State* L, lua_Debug* ar);
/* gets called when thread execution is interrupted by break in another
* thread */
void (*debuginterrupt)(lua_State* L, lua_Debug* ar);
/* gets called when protected call results in an error */
void (*debugprotectederror)(lua_State* L);
};
Assuming you cache the global_State when creating the main thread (which you
should - it's just L->global), you can set g->cb->userthread to a C function
to define what should happen when a new thread is created or destroyed.
This can be used to:
* Inherit userdata from parent threads; great for permission models.
* Run destructors on userdata when threads are collected; great for resources.
That is a lot of information to digest, but if a Luau dev reads this, they'll
probably have said "yep, exactly" at least once. Documenting this small aspect
of the VM will be another step towards making it a bit friendlier for people to
start using Luau.
Obviously, the more technical documentation will remain here (in this commit &
pull request), but even the public facing documentation (which developers, like
me, will reference) should contain information just like the thread identity
section that was removed.
Hopefully, this is a suitable replacement, as thread userdata IS available in
the open-source version of Luau - and is used by Roblox for its "extra space" to
store things like thread identity.
Full documentation for the standard library, written from scratch by looking at the source code - so hopefully this is reasonably correct/precise.
Some of the function descriptions are probably too concise to be easily understandable - we can flesh this out in the future.
Some of the type specifications aren't using valid Luau syntax; in particular, I've used "function" or "table" in a few places as a human-friendly notion that any function/table suffices, and the iterator functions just say that they return <iterator> without being specific as to what the signature of the generator is.
* July post is ready
* Trigger a build
* Trigger a build
* Added a paragraph for 'DuplicateConditions' lint
* Apply suggestions from code review
Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com>
* Fix mixed tabs and spaces
Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com>
* Template for the June post
* June post is ready
* Fixed post date
* Added a few examples
* Add another equality operator
* Update docs/_posts/2021-06-30-luau-recap-june-2021.md
Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com>
* Note the limitation of current constraint resolver
Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com>
Restore the original sentence with tweaks; this seems like better wording since it highlights the importance of knowing the field name at compile time, no matter the notation.
* Added May 2021 recap post
* Added missing items and fixed confusing function declaration example
* Apply suggestions from code review
Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com>
* Small fix
Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com>