|Anonymous | Login | Signup for a new account||2021-01-15 21:30 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008007||opensim||[REGION] Script Functions||public||2016-08-25 11:56||2018-08-27 04:27|
|Platform||PC||Operating System||Windows||Operating System Version||10|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0008007: Defaults in osslenable.ini are not in line with threat levels for functions-- recommended tweaks|
|Description||There are several functions with a threat level of None or VeryLow which are currently being restricted from all besides the estate owner and estate manager. They are useful functions that I believe should be set to TRUE so they are available for anyone to use by default.|
I have scripted object on various grids that make sure of these functions, which has not been an issue in the past. However, when a grid implements a more recent version of opensim (as Virtual Highway did recently), it prevents these functions from running. (Yes, I do have a vested interest in this; however I think it's a change that will benefit everyone)
|Tags||No tags attached.|
|Git Revision or version number||d5f376a4b10ffdb5acc17d4e350a0a523ba0e9f5|
|Run Mode||Grid (1 Region per Sim)|
|Environment||.NET / Windows32|
Robert Adams (administrator)
These are restricted because they allow griefing and region overload. Invite to group can be used to bug everyone around (fetched with osGetAvatarList). The dynamic texture functions create new assets and thus can easily overload the local cache and the grid asset server with many, many generated textures.
Thus all these fall under the category of "only to be used in scripts you trust" and not just any ol' script. That is why their default is to only allow the restricted set of users.
Mata Hari (reporter)
In addition to that, remember that by many people do allow visitors to run scripts in their regions which means setting a low threat level for those means people can grief via HUD or worn attachment even if they don't have build rights.
One would hope that most hosting service providers would thoroughly and carefully check any changes to settings in the various ini files and adjust them according to their users' needs prior to applying an update.
|Okay. In that case, the threat level for these functions should be changed to high. It makes no sense for one source to say they are not a threat, and another to say they are.|
|What about osTeleportOwner? I would still vote for that to remain open, since it only teleports the owner of the object, and it allows hypergrid teleports. If the concern is people receiving a HUD that unknowingly teleports them, then the function could be changed to require them to grant permissions first if the script is not owned by an estate owner or manager.|
greg override the settings you need on opensim.ini (or better on file you include there)
this way they remain as you like.
Our defaults can change, according to our view of the best setting for the majority of users.
I will shut up about this. Of course I know I can change the settings on my own grid. I was trying to address two things. First, there is now an inconsistency between the way that threat levels are assigned to some functions and way that osslenable.ini treats the same functions. If a function is truly dangerous because of griefing potential, then you should set the threat level higher.
The second concern I had was that I do have opensim products in stores that make use of some of theses functions, and they will be rendered useless on grids that upgrade to the latest version and choose to leave the defaults as is. I understand the points that were made, and I accept the fact that this is my problem and I will deal with it as needed.
We will review that at some point.
The defines at OpensimDefaults.ini do override the code settings,
so sometimes its just faster changing there than on both places.
guess that's why we now have a desync and possible its time to review :)
thx for remembering this.
Seth Nygard (reporter)
I believe all the OSSL functions and their defined threat levels should be reviewed and revised as necessary. I don't think many people understand even how a threat level has been defined. I never use the threat levels to decide a functions permission level but I know many who do.
Determine the "best" threat level to assign to a specific function is not so easy in some cases. Depending on its use and everyone's expectations opinions will vary.
I think with the new xEngine and yEngine it's a good moment to go through all the functions and see what threat level they should get.
Grid owners can always deviate from those default settings if they want
|2016-08-25 11:56||greg0254||New Issue|
|2016-08-25 13:28||Robert Adams||Note Added: 0031058|
|2016-08-26 06:17||Mata Hari||Note Added: 0031059|
|2016-08-26 10:07||greg0254||Note Added: 0031060|
|2016-08-26 10:22||greg0254||Note Added: 0031061|
|2016-08-26 10:27||UbitUmarov||Note Added: 0031062|
|2016-08-27 14:18||greg0254||Note Added: 0031064|
|2016-08-27 14:30||UbitUmarov||Note Added: 0031065|
|2016-08-28 10:17||Seth Nygard||Note Added: 0031073|
|2018-08-27 04:27||Fly-Man-||Note Added: 0032892|
|2018-08-27 04:27||Fly-Man-||Status||new => acknowledged|
|Copyright © 2000 - 2012 MantisBT Group|