Security context

Scripts on Roblox have a thread identity which indicates what security access they have to the scripting API. Some class members in the scripting API can only be used by scripts that have the required permission.

Identities

A thread identity is an identity (an integer) given to a thread that indicates which permissions it has.

The identity of a thread can be found by using the printidentity function. This function will print the identity of the thread, prefixed by the last argument given to it if it is a string or a number, "(null)" otherwise, and a space. If no argument is given to it, it will prefix it by "Current identity is", followed by a space.

Example

In a script with identity 2, printidentity() would show Current identity is 2 in the output.

The identity of a thread will usually depend on where it comes from. For example, threads executed as plugins have an identity of 6, threads running code from the command bar or the "execute script" option have an identity of 5, and scripts and local scripts usually have an identity of 2.

Identities

Identity	Description
0	Anonymous threads
1	User-initiated actions in Roblox Studio
2	BaseScript objects in any DataModel
3	BaseScript objects in any DataModel, in a place created by Roblox
4	BaseScript objects in any DataModel, if they were authored by Roblox
5	Studio command bar, "Execute Script", -script command line parameter
6	Studio plugins, COM API
7	Web service API
8	Receiving data via replication

Permissions

Each property, method, event or callback in the scripting API may require a permission. The existing permissions are PluginSecurity, RobloxPlaceSecurity, LocalUserSecurity, WritePlayerSecurity, RobloxScriptSecurity, RobloxSecurity, TestLocalUserSecurity, ScriptWriteRestricted: [NotAccessibleSecurity], and ScriptWriteRestricted: [PluginSecurity]. All threads have access to members that do not require a permission.

Permissions

Permission	Description
None	Any identity can access this feature, including in-game scripts.
Plugin	Second-lowest access level, just above in-game script.
RobloxPlace	Places created by Roblox, where scripts are more trusted and preliminary features are allowed.
LocalUser	Non-game permission, usually for Roblox Studio.
WritePlayer	Permissions for changing player name, user ID etc.
RobloxScript	A script, such as a CoreScript, that is run inside a game.
Roblox	Highest level of permission.
TestLocalUser	In test builds, this is equivalent to no permission, but in regular builds it is equivalent to LocalUser.

Roles

The table below shows which permissions are associated to each identity.

Roles

Identity	Permissions
0	None
1	Plugin, RobloxPlace, LocalUser
2	None
3	RobloxPlace
4	Plugin, RobloxPlace, LocalUser, RobloxScript
5	Plugin, RobloxPlace, LocalUser
6 (studio build)	Plugin
6 (non-studio build)	All permissions
7	All permissions
8	RobloxPlace, WritePlayer, RobloxScript
Anything else	None, plus an assertion failure

Virtual machines

Threads with different identities can be run with different Lua virtual machines, so that user scripts are not mixed with scripts authored by Roblox. There are currently only two virtual machines, one for CoreScripts and other threads that have RobloxScript access and another for all the other threads. In studio builds, there is a third virtual machine used for studio plugins.

Additional restrictions

If the RobloxLocked property of an object is true, only scripts with the Plugin permission will be able to index signals and children of the object, set its properties or assign its callbacks, call yielding functions of the object, change the parent of the object's children, or create objects with the object as the parent using Instance.new(class, parent). Furthermore, scripts that do not have this permission will not be able to call non-yielding functions of the object unless it is not a descendant of CoreGui. This property is used, among other things, for GUI objects created by CoreScripts.

See also

• List of members by security