Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007911opensim[REGION] Script Functionspublic2016-05-21 09:392016-12-14 08:41
ReporterJeffKelley 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Statuspatch includedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007911: OSSL proposal : osDie(LSL_Key)
DescriptionWhy osDie? Because we can rez objects by script, change any of their properties with osSetPrimitiveParams (including PRIM_TEMP_ON_REZ), but not dispose of them immediately.

The usual way to control dynamically rezed objects is to include a script in the object template, then send commands to the rezed instances to adjust size, position, rotation, and finally destruction. This is tedious since we need to edit the script in the template, take it into inventory, remove the template from the rezer and replace it with the new version.

osSetPrimitiveParams offers a scriptless and straightforward alternative. Except for disposing.

Example applications : a multichair, rezing seats when needed and derezing when not. The idea to write osDie came along the project of a dynamically configurable theater, rezing, moving, and derezing up to 500 seats. (TEMP_ON_REZ was used before)

Security : osDie has ThreatLevel high, the same as osSetPrimitiveParams, and can be allowed selectively with Allow_osDie.
TagsNo tags attached.
Git Revision or version number
Run ModeStandalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineBasicPhysics
Script Engine
EnvironmentUnknown
Mono VersionNone
Viewer
Attached Filespatch file icon 0003-Add-osDie-key.patch [^] (3,739 bytes) 2016-05-21 16:00 [Show Content]

- Relationships

-  Notes
(0030344)
Mandarinka Tasty (reporter)
2016-05-21 10:37
edited on: 2016-05-21 10:45

Hi Jeff !

Your idea is clear, but this function is like powerful weapon.

The potential risk of using it, is giant for me.

Setting high thread or even severe is absolutely still vulnerable for griefing attack.

Even if theoretical resident John Smith uses it in form:

Allow_osDie = John_Smith_UUID, then still it is dangerous.

Because: anyone can send gift to John and ask him: please rezz or wear.

Next, all objects in the scene = region, can be deleted and next also

database removes their entries.

So all prims will be wiped out, not only John's prims but other prims in the region too !

Extremely dangerous function in same way like osConsoleCommand.

In SL, there are two functions that can return objects:

llReturnObjectsByID and llReturnObjectsByOwner and they are secured by strict conditions like: PERMISSION_RETURN_OBJECTS

So in my opinion, you should secure usage of this osDie in kinda similar way.

1. script must be granted by owner of the script in the way:

llRequestPermissions(llGetOwner(),PERMISSION_DIE_OBJECTS)

so it would require creating new flag in Opensim: PERMISSION_DIE_OBJECTS

2. Script must be located on the parcel owned by script's owner.

something like that: if (land.LandData.OwnerID == m_item.OwnerID)

3. script can delete only objects owned by script's owner, if not then stop:

if (obj.OwnerID != m_host.OwnerID)
                return;
4. Also this if (World.Permissions.CanRunConsoleCommand(m_host.OwnerID))

should be considered as security layer.

5. owner of the script should be the same perosn as creator of the script

there is no such class so far, but i have published such proposal to add additional defence: http://opensimulator.org/mantis/view.php?id=7901 [^]

But in my opinion, it is too dangerous to apply it in the core.

Certainly I understand the purpose of your proposal.

Regards

PS: I have forgotten to write:

This functionality even exists now via osConsoleCommand:

osConsoleCommand("delete object id");

(0030345)
JeffKelley (reporter)
2016-05-21 10:43

osSetPrimitiveParams can set PRIM_TEMP_ON_REZ and your objects are gone.
(0030346)
Mandarinka Tasty (reporter)
2016-05-21 10:47
edited on: 2016-05-21 10:50

But in the code referring to osSetPrimitiveParams, you have at least one defence:

if (obj.OwnerID != m_host.OwnerID)
                return;

And in my grids i do not allow for osSetPrimitiveParams:

Allow_osSetPrimitiveParams = false

But i do not negate osDie made by You, I only indicate eventual, potential

vulnerabilties.

(0030347)
JeffKelley (reporter)
2016-05-21 10:52

if (obj.OwnerID != m_host.OwnerID)
                return;

is a welcome amendment.
(0030348)
Mandarinka Tasty (reporter)
2016-05-21 10:53

Yes: ) but don't you consider that it is too little ?

We do not need to repeat the same what others used to create osSetPrimitiveParams,

We can create better security :)
(0030349)
JeffKelley (reporter)
2016-05-21 11:06
edited on: 2016-05-21 11:13

I'm willing to change ThreatLevel and add your ownership test.
I won't add a PERMISSION_DIE_OBJECTS. Anybody is free to expand.

We have ThreatLevel + individual permissions to tune the security level. If one give an object to John Smith asking him "rezz or wear", and John Smith is allowed to run osConsoleCommand, you get same threat. Shielding from osDie is not different from shielding from osConsoleCommand.

Your remarks are welcome.

(0030350)
melanie (administrator)
2016-05-21 12:13

The way I see it, there are two kinds of grids. Those that allow users to script and build, etc, and need to exercise care with what to allow and those that let the user experience an environment with interactivity, but without creation.

The former need security and the latter need control. As all osFunctions can be turned on and of individually, in groups and by level, I really don't see how this one would be worse than any other. The ownership check makes sense. Apart from that, I'm all for this one.
(0030351)
Mandarinka Tasty (reporter)
2016-05-21 13:13

yes, Melanie :)

For example: default file osslEnable.ini that exists in OSGrid default

configuration, has the following setting:

Allow_osSetPrimitiveParams = false

You may check it.

And OSGrid is grid that ( from its definition ) allows for much more than

commercial grids in aspect of permissions.

Anyway, I am also for this proposal, that is logical consequence of

construction of osSetPrimitiveParams, like its complement.
(0030352)
Mata Hari (reporter)
2016-05-21 15:05

I'm in favour of this one with threat level of either VeryHigh or Severe (I think VeryHigh would be in line with the potential risk it involves and other functions with that threat) and I agree that it's the sort of function that really should only work for cases where the script owner == target object owner
(0030353)
JeffKelley (reporter)
2016-05-21 16:03

Updated patch.
 - ThreatLevel raised to VeryHigh.
 - Ownership test added.
(0030936)
gimisa (reporter)
2016-07-15 10:33

Jeff , I agree your function is handy . But since it was not existing , I use a different approach to a giver I made you can find in gimisaOS.

It uses llRezObject and osForceCreateLink. The giver rez the object demo object without any script in it .

It then rez a second object call the dieControler containing the script to die both. Then the rezzer sends a force link command ( regular llCreateLink would work but request permission confimation is not always available specialy on region restart ) so that the dieControler attaches to the item to be deleted as root. A trigger command is then use to delete the set. Easy to modify if you want the mer fact of success link to die .

The giver itself handle giving object the usual way . This effort is necessary to keep the demo object free of scripting for the user. Simply inserting in the giver inventory is enought for the scripting to do its magic. Totaly transparent to user.


Hope it helps
(0031361)
Total Sorbet (reporter)
2016-12-01 03:41

This would make a useful addition for gaming scenarios also: Unscripted visible bullet(s) could hit scripted target/enemy which could sense the collision, do their housekeeping and osDie() the bullet.

Mmn I could use some osDie()
(0031410)
JeffKelley (reporter)
2016-12-07 10:45

Core seems to like this patch. Let's wait for 0.9 dust to settle, and it will be time to ask for a commit. In the meantime, you can branch your own repo.
(0031411)
djphil (reporter)
2016-12-07 11:15

I was glad to note that it is expected that this function will not fail in silence if the uuide is not found on the region, that is a good thing!

I hope this patch will be applied soon :)
(0031451)
UbitUmarov (administrator)
2016-12-14 08:41

patch on master and then changed.
Only allow osDie() on objects rezzed by the script prim Group (linkset) or on it self.

- Issue History
Date Modified Username Field Change
2016-05-21 09:39 JeffKelley New Issue
2016-05-21 09:40 JeffKelley File Added: 0003-Add-osDie-key.patch
2016-05-21 09:40 JeffKelley Status new => patch included
2016-05-21 10:37 Mandarinka Tasty Note Added: 0030344
2016-05-21 10:43 JeffKelley Note Added: 0030345
2016-05-21 10:45 Mandarinka Tasty Note Edited: 0030344 View Revisions
2016-05-21 10:47 Mandarinka Tasty Note Added: 0030346
2016-05-21 10:50 Mandarinka Tasty Note Edited: 0030346 View Revisions
2016-05-21 10:52 JeffKelley Note Added: 0030347
2016-05-21 10:53 Mandarinka Tasty Note Added: 0030348
2016-05-21 11:06 JeffKelley Note Added: 0030349
2016-05-21 11:13 JeffKelley Note Edited: 0030349 View Revisions
2016-05-21 12:13 melanie Note Added: 0030350
2016-05-21 13:13 Mandarinka Tasty Note Added: 0030351
2016-05-21 15:05 Mata Hari Note Added: 0030352
2016-05-21 16:00 JeffKelley File Deleted: 0003-Add-osDie-key.patch
2016-05-21 16:00 JeffKelley File Added: 0003-Add-osDie-key.patch
2016-05-21 16:03 JeffKelley Note Added: 0030353
2016-07-15 10:33 gimisa Note Added: 0030936
2016-12-01 03:41 Total Sorbet Note Added: 0031361
2016-12-07 10:45 JeffKelley Note Added: 0031410
2016-12-07 11:15 djphil Note Added: 0031411
2016-12-14 08:41 UbitUmarov Note Added: 0031451


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker