[Opensim-dev] Test before you call OSSL function

Fri Oct 18 06:32:36 UTC 2019

The threat levels are obsolete and they have been superseded by the 
Allow_<func>= lines in the osslEnable.ini initialization file. Every 
region reads a copy of this file when it boots. If there is an 
Allow_...= line for a function, that can allow region owners, estate 
managers, gods, parcel owners, specific avatars by UUID to call the 
function or combinations. It can enable each function one at a time for 
all to use or disable them one at a time for everyone. If there is any 
Allow_...= line in the INI files, the threat level is never checked. So 
threat levels could be thrown out. EXCEPT that since they are still 
there some people still use them (like LBSA Plaza, the place you arrive 
by default in OSGrid, the testing ground of Open Simulator). So as 
someone trying to be a professional scripter I'd like to make sure my 
code works even in the cases where region owners still rely on threat 
level. Too bad threat level is hard-coded into each function and not 
readable by any other function. I'm building my own table with a copy of 
this information so I can use that copy to do the test.

It was pointed out to me that finding out WHY a script generated an 
error is a potential security violation. Getting a message that says 
"you can't run that function because the threat level of this region is 
VeryLow and this function is Moderate" gives a griefer information about 
what will work here. The correct secure way for the function to work is 
to just return TRUE if the function will work and FALSE if not. I can do 
that. I don't care WHY I should not call a function only if I CAN or 
not. I don't care if it is because of Allow permissions or threat level. 
I just want to know that if I skip calling a function, an annoying 
incomprehensible message WILL NOT appear.

Note that the threat level can be different in every region, even in one 
grid. The Allow_...= permissions can also be different in every region. 
So a script would like to know every time it changes region, or grid, 
what is safe to call and what is not.

On 10/17/2019 9:09 PM, Mike Lorrey wrote:
> Been  lurking for  quite a while, and I have to ask, Mel mentioned that the
> threat warnings were created to protect against a griefer threat that never
> materialized. If the perceived threat never happened, why are we keeping
> the threat levels at all? Keeping  them is the same sort of illogic for
> keeping a government agency funded and operating despite having nothing to
> do, like regulating buggy whips. How about we turn this stuff off
> completely? I don't need to deal with OSSL functions if I wanted to grief
> opensim, theres plenty of LSL functions I could use to bring a grid to its
> knees if I wanted to. Furthermore, the main threat in opensim, the problem
> of copybotters, the devs do absolutely nothing about, so you cannot claim
> to be protecting us against a nonexistent threat when you are doing nothing
> about a real threat.
>
> On Thu, Oct 17, 2019 at 3:51 PM Dahlia Trimble <dahliatrimble at gmail.com>
> wrote:
>
>> In SL we used to set up error event handlers with a listener on
>> DEBUG_CHANNEL. Errors will still show in red on the script debug window but
>> you're script will be able to be aware of the error(s). I don't recall if
>> I've ever tried it on OpenSImulator but I'd be surprised if it didn't work
>> there also.
>>
>> Users don't usually see the red text as most keep the script debug window
>> open.
>>
>> On Thu, Oct 17, 2019 at 11:05 AM Mike Higgins <mike at kayaker.net> wrote:
>>
>>> I agree that many functions are dangerous, and some grid owners may
>>> shoot themselves in the foot by enabling them. But I am talking about
>>> writing scripts that behave in a professional way, so I can hand them
>>> out for lots of people to use. If I wrote a phone app that popped up
>>> internal error messages in some locations, this would be considered very
>>> unprofessional and people would down-vote my app and stop using it. Most
>>> programming languages have a try/catch (or on_error) flow control
>>> construct, but LSL does not. I would love to add such a construct to LSL
>>> but I do not have the skill to add that to the language. (I'm of the
>>> opinion that a new error event rather than an error state is the way to
>>> go).
>>>
>>> I do have enough skill to add an osPermissionToCall function that
>>> returns some information about the OSSL functions. I agree this is not
>>> ideal, but I could write the code for this function and submit it to the
>>> Devs, saving them from needing to do this trivial task and saving them
>>> from the more difficult task of adding error catching to LSL. Ubit tells
>>> me he would reject this try-before-you-call submission. But I assume he
>>> does not have the time to do the better option of adding an on_error()
>>> state to the language. The result is that there is no way for us
>>> scripters to write professional programs in OpenSim.
>>>
>>> Here is the scenario I am looking at: I write a useful script that
>>> people want to use as they hypergrid around. I thought it was safe to
>>> call osGetGridName which seems an innocuous function and will probably
>>> be allowed everywhere. But it turns out that osGetGridName has a
>>> "moderate" threat level and some places, (most notably LBSA Plaza in
>>> OSGrid), have the threat level set to "Very Low" and do not have an
>>> “Allow_” line to override this for osGetGridName. So my script works
>>> most places in the Metaverse, but fails and pops up messages when one of
>>> the users of my script shows up there. I would love to catch that error
>>> and do something reasonable with it. But LSL has no way to do this and
>>> the developers are resisting alternative ways to do this. (In the case
>>> of osGetGridName, I could catch the error and substitute “OpenSim” as
>>> the grid name, or have the script tell my users “Sorry, I can't tell
>>> where you are now”).
>>>
>>> There was a secondary issue that when osGetGridName fails, it not only
>>> popped up an internal error message, but it sends that message to every
>>> avatar in the region. Ubit has thrown me a bone by adding an option to
>>> the INI files that suppresses this behavior and only sends the message
>>> to the user of the script. This has several problems: 1) Note that it is
>>> the user of the script that gets the message, not the scripter. 2) Most
>>> of my users and most of the avatars that get this message are that:
>>> USERS, not grid owners who have the power to change the INI file. Since
>>> they can't effect the outcome, they will stop using my script. And all
>>> scripters like me will just stop calling ANY of the OSSL function in the
>>> scripts we hand out. Even the innocuous looking ones. And all the effort
>>> that the Devs have spent on writing the OSSL functions will have been
>>> wasted.
>>>
>>> Imagine that I write a phone app that works fine on the SPRINT network
>>> but pops up internal error messages when you are roaming on AT&T. But
>>> then it paws through my contact list and also sends a copy of that
>>> incomprehensible error message to all my friends. Ubit has given me
>>> equivalent of a tool that can stop that last behavior, but only if
>>> SPRINT and AT&T change some internal flag on their servers. Unlikely to
>>> happen. People are still going to get error messages and stop using my
>>> phone app.
>>>
>>> Then there is an additional problem: Currently there is no way for an
>>> osPermissionToCall function to know what the threat level is for any of
>>> the other OSSL functions. That threat level is hard-coded into each
>>> function. Ubit resists moving that information to a central location in
>>> the code. He also resists moving this information into the INI files.
>>> But I still want to find a way to write professional scripts on OpenSim.
>>>
>>> So if you are still reading this Ubit: Would you accept a patch with an
>>> osPermmissionToCall function that was completely self contained and did
>>> not require changing the location of the threat level values? For
>>> example, the osPermissionToCall functioin could have a local table of
>>> all the other functions and their threat levels. This might introduce
>>> bugs if threat levels ever change, but that seems unlikely.
>>>
>>>
>>> On 10/17/2019 8:10 AM, Leal Duarte wrote:
>>>> Well lets try put some perspective on this...
>>>>
>>>> The problem is not how hard it is to detected and handle disabled
>>>> functions
>>>>
>>>> The problem is WHY are you using them !!!
>>>>
>>>> See OSSL got a lot a functions in time and for very different reasons.
>>>>
>>>> Many are there because they are just funny/useful on very specific
>>>> regions or cases.
>>>>
>>>> Once the allow control was introduced, that got worse, because as dev
>>>> in can just not care, i just flag a specious feature as SEVERE,
>>>> ESTATE_OWNER only. And just let you change it and shoot your own feet,
>>>> or worse someone else feet...
>>>>
>>>> And in many cases you are just doing that. ( the C# scripts was a
>>>> example i just had to kill )
>>>>
>>>> see a very simple and useful(?) example
>>>>
>>>> osGetNotecardLine(..)
>>>>
>>>> none of that Dataserv mess of llGetNotecardLine(..) right?
>>>>
>>>> well wrong.. Dataservice is need because the notecard may be on a
>>>> assets server on the other side of the world...
>>>>
>>>> and not using it will stall the engine thread, potentially all of then.
>>>>
>>>> Why do i see its  errors at osgrid LBSA ?
>>>>
>>>> A lot more examples, but you got the point.
>>>>
>>>> When one writes a script, one must take in consideration its target
>>>> audience..
>>>>
>>>> you can't use osSlerp()  if you want it to run at current Kitely, can
>>>> you?
>>>>
>>>> So issue is to identify a set that should be universally supported,
>>>> and everyone make the effort to support it.
>>>>
>>>> ...
>>>>
>>>> Ubit
>>>>
>>>>
>>>> On 17-Oct-19 15:17, dz wrote:
>>>> ......
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>