jump to navigation

Preventing user script execution in OpenSim applications December 5, 2008

Posted by justincc in opensim, opensim-applications, opensim-tech-basics.

opensim-logo-short-padlockOpenSim 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

save-permission-deniedNow 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.



1. juancarlos - December 7, 2008

Pienso que esta bien, pero espero no pase mas de ahi,
la libertad de los usuarios no deberia ser limitado por un par de server owners,
eso seria ser ” Elitistas “, la libertad y la comvivencia deberia tratar de ser consensuada entre todos,
ademas que hay muy pocos usuarios, si no pueden ejecutar sus propios scripts le quita la diversion,
convivir y ser sociables, para eso hay chat, foros, irc, y jerarquias.

2. justincc - December 9, 2008

Hi Juan. I’ve taken the liberty of translating your comment to English (since my Spanish is non-existant). Google appears to do a remarkably good job

“I think that is fine, but I hope not go over there,
the freedom of users should not be limited by a pair of server owners,
That would be “elitist”, freedom and comvivencia should try to be consensus among all,
besides which there are very few users, if they can not run their own scripts takes away the fun,
live and be sociable, so we must chat, forums, irc, and hierarchy.”

Yes, this facility is largely aimed towards people using OpenSim in an application, rather than in a public grid. However, in principle it could be used (somewhat unsuccessfully at the moment) on a public region. Though you could argue that a region owner can do what they like, it is an interesting question as to whether one might expect avatars to have “rights” (e.g. the right to run certain scripts).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: