Preventing user script execution in OpenSim applications December 5, 2008Posted by justincc in opensim, opensim-applications, opensim-tech-basics.
OpenSim aims to be a general virtual environment platform, useable as a basis for software applications as well as public virtual worlds.
However, for an application to use OpenSim with the Second Life protocol and client there are some restrictions that we may want to apply that would either not be desirable or would be impossible to enforce in a public virtual world.
For instance, suppose that you wanted to use OpenSim as part of a virtual business conferencing application. You may want to allow users to be able to copy and execute pre-existing scripts (for example, so that they can display and flip between slides on a projector screen) but not let them be able to create scripts that send any user within range their business card. This might be done to perserve the user experience or for various other reasons.
How might the ‘no auto-sending business cards restriction’ be enforced? In this particular case, one could stop LSL methods such as llGiveInventory() from executing (this can’t currently be done in stock OpenSim but it would be easy enough to patch the code such that this method doesn’t do anything). However, one might want to go a step further and stop any user script from executing. The rest of this blog post explores how we can currently do that.
Of course, there are various trade-offs from going down this route. On the plus side, preventing user scripts entirely would make scripting engine performance more predictable. Support costs could be reduced since there won’t be any scope for user scripts to interact with other scripts and avatars in unpredictable ways. This reduction in unpredictability would also make the user experience more uniform.
The flipside of a reduction in unpredictability is a lower level of direct customization for ordinary users. They would no longer be able to directly write their own scripts to provide functionality that the original designers never thought of, either for public consumption or for personal use (e.g. huds). It would still be possible to get these scripts in via an administrator but this is often a painful barrier to cross.
Suppose that you did want to go ahead with stopping users from running their own scripts. In this case we can’t simply stop scripts belonging to ordinary users from executing at all since in the business conference application we still want them to be able to run pre-canned scripts. One approach is to only allow scripts to execute that have certain checksums (which acts as fingerprints). This could be quite good in a finalized application where no new scripts are being created or introduced.
However, the approach that we’re going to explore here is one where ordinary users are prevented from editing existing scripts or creating new ones in the first place. In OpenSim (as of r7623, post 0.6), this can be done by tweaking some settings in the OpenSim.ini file. First of all, you have to have permissions enforcement turned on with the following entry (it is actually turned off by default).
serverside_object_permissions = true
In order to allow administrators/gods to still be able to edit and create scripts, one also needs to make a setting to allow god mode.
allow_grid_gods = true
Finally, there are two settings to affect who can create and who can edit scripts. To restrict script creation, the settings need to be changed so that only administrators/gods have these abilities
allowed_script_creators = gods allowed_script_editors = gods
Now when OpenSim is restarted, only users that are gods can create and edit scripts. For other users, selecting the new script option in the Linden Labs client interface will have no effect and saving edited scripts will not be possible (this is a situation where one could possibly remove these options from a client altogether).
There’s currently no good core OpenSim way of conferring and removing god status from users, though external projects may provide one. At the moment to make a user an administrator you have to directly change a setting in the user database, with an SQL command such as
update users set godLevel=400 where username="Justin";
400 is the magic number where a user is considered an administrator.
As this solution for stopping user script execution relies on preventing them from creating or editing scripts, it is not really useful in situations where the region is connected to a public grid where the are region or grid servers controlled by a third party, as scripts can then be inserted at the grid servers directly or simply be imported over the border from other region servers (this is a situation where a fingerprinting approach may be more useful).
At the moment I would regard this approach to preventing user script execution as experimental. Although the obvious routes to creating and editing scripts have been sealed off, there may still be some obscure method that remains viable (though I hope this is unlikely). Any help in plugging gaps that exist would be much appreciated.