[Opensim-dev] osNPCxxx functions vs security

Justin Clark-Casey jjustincc at googlemail.com
Fri Jul 6 21:46:45 UTC 2012


If there is the possibility of abuse, then you're right in that the more general problem lies with any avatar.  An 
external libomv bot can also touch anything in the simulator its logged into as rapidly as it can punch the requests 
over to the simulator.

I hear that this kind of event overloading shouldn't be possible in the event mechanism.  If there is a problem, then 
from the scripting perspective I would rather see us try to solve it in the first instance with simple configurable 
script delays (as already done in LSL) rather than create more complicated mechanisms.  Keep it simple!

General limiting of events is a more complicated issue that can be tackled at some other time if required. I think.

Regarding npc touch duration, this certainly could be added as an option to an overloaded osNpcTouch() in the future.

On 05/07/12 16:34, Bob Wellman wrote:
> This thread has started me thinking more generally about the timings of repeat osNPCTouch commands causing event
> overloading.
>
> When a real avatar touches an object he left clicks on an object and sometime later he releases the left click button.
> In other words his touch has a certain duration to it. This triggers a number of LSL events as show in this excerpt from
> the LSL wiki
>
> *Event:*	*Triggered:*	*Triggered multiple times:*
> touch <http://lslwiki.net/lslwiki/wakka.php?wakka=touch>()	/while/ a user is clicking on the object.	YES
> touch_start()	when a user /starts/ clicking on the object.	NO
> touch_end <http://lslwiki.net/lslwiki/wakka.php?wakka=touch_end>()	when a user /stops/ clicking on the object.	NO
>
>
> The time gap between start and end is sometimes used to control how the touch object behaves. For instance in a golf
> script the longer the touch the harder the golf ball is hit.
>
> I can foresee that some time in the future we may wish to add a "duration" parameter to the osNPCTouch command so NPCs
> can use these kind of touchable objects. As the touch event is triggered multiple times during a long touch that could
> also lead to misuse.
>
> However whether or not we implement osNPCTouch or not we have a problem. A real avatar (or a bot) can still do a long
> touch on an object containing a script such as this "golf" script and cause many touch events to fire very rapidly
> unless we limit them in some way.
>
> So maybe we should first look at how to prevent that and extend it to NPCs doing very rapid repeat touches as well.
> Remember Bots can generate touches as fast as NPCs.
>
> My first thoughts is a opensim.ini configuration parameter max_touch_events_per_second that limits how frequently the
> touch event can be fired in a script regardless of who (avatar or NPC or bot) is doing the touching. Next we need to
> control the rate of repeat firing of the touch event during a long touch. I take it that LL has some mechanism to
> control how frequently the touch event is fired between the touch_start and touch-end event. Some study of how they do
> this may help with a solution to limiting repeat touches too.
>
> So in this way we stop scripts processing touch events too rapidly protecting them from abuse by avatar or NPC or bot.
> Scripts can then not be driven so hard that they crash the sim.
>
> However from something Dahlia mentioned I believe event triggers are queued pending sending to the script for
> processing. So, if we did this limiting how often events can be accepted by a script, I would then assume rapid touching
> abuse by an NPC (or a bot) would now cause a queue of touch events pending to build up. So we would maybe also have to
> limit the number of touch events pending that could be queued too in some way.
>
> My suggestion would be an opensim.ini configuration parameter max_touch_events_queued to limit the size of this queue.
> Once the queue limit is reached further touches are ignored until the queue empties a bit.
>
> Basically I am saying:
> 1) Get the script to protect itself from abuse from events coming off the event queue too fast (pushing the problem back
> to the event queue).
> 2) Get the event queue to protect itself from too many events entering the event queue faster that we can clear them.
>
> Just my thoughts... hope it makes sense... feel free to disagree.
>
>
> ------------------------------------------------------------------------------------------------------------------------
> Date: Thu, 5 Jul 2012 14:18:17 +0100
> From: wanderingcodesmith at yahoo.co.uk
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] osNPCxxx functions vs security
>
> Sorry this is probably out of the original thread, i just joined the list!
>
> I think that any large delay on the osNpcTouch function would not be right, at least 10 touches a second should be
> allowed, i can easily click that fast for several seconds  at a time.
>
> Also the NPC should be allowed to click its own/owners objects at any speed, and others objects at any reduced rate that
> may be decided upon. For "own" items it is just another method of script comms, no different to chat on a non  zero chat
> channel and that is not restricted, but this allows third party scripts written around touch events to be used without
> alteration.
>
> NPC functions are already threat level high and NPCs have to be intentionaly configured in addition to specifically
> allowing OSSL in the first place
>
> If you want to disable certain OSSL functions there are the Allow_osxxx = false settings in OpenSim.ini, the options
> give a big choice in how you restrict OSSL use.
>
> Talun
>
>
>
> _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


-- 
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc





More information about the Opensim-dev mailing list