Erm. The option to COMPLETELY disable OSSL needs to be preserved.....
It can't be that there is no option available that doesn't allow opensim to be reduced to LSL ONLY Just saying' - Melanie ---- On Tue, 15 Oct 2019 23:17:42 +0000 Leal Duarte <mailto:ajldua...@sapo.pt> wrote ---- Threat Level is a default fallback.. if a valid line Allow_funcName in present on the file it is ignored. That is all the needed flexibility (we ship with all present) So we will not make things even more complex than they are. meanwhile: <cia-opensim> add OSSL option PermissionErrortoOwner (true or false). if true ossl functions permission errors will only be sent to prim owner, default false: send all around <cia-opensim> http://opensimulator.org/viewgit/?a=commit&p=opensim&h=d79d7e228a059e40a9334c9e2ec4c81075443f83 Ubit On 15-Oct-19 18:10, Melanie wrote: > Asset bloat from normal use is quite manageable in today's computing > landscape, artificially and maliciously introduced asset bloat, less so. > However, I was only ranting there :) > > My first three bullet points are really what I was getting at: > - Retaining enable/disable for the functions that now have it > - Changing from the hardcoded schema, but without it getting slower in the > process > - Not disabling by default anything that the current default doesn't disable. > It's OK to enable more by default. > > That doesn't in any way preclude improving the situation. It just ensures no > nasty surprises for region owners. > > - Melanie > > > > > ---- On Tue, 15 Oct 2019 17:04:22 +0000 dz <mailto:mailto:d...@bitzend.net> > wrote ---- > > > Get Serious PLEASE > > Melanie sez... > "*Another is osMakeNotecard, with which a script in a tight loop can create > 10s of thousands of notecard assets.*..." > > UMMM.. lets see... I'll have to agree that is ONE possible > disadvantage... But let's look at a bigger picture.. > Anyone with rez rights can DOS a sim simply by continuously rezzing > object ( not notecards) into the available space. > Anyone can use base LSL texture change functions on a relatively small > number of objects ( with multiple faces and multiple scripts) to > monopolize the script resources of a region. > Anyone with simple scripting skills can rez and retrieve objects at > close to the same speed, and introduce the same asset base bloat issues. > > So your argument about notecards has some merit, but it isn't unique > to the OSSL function or even notecards. > > ( Please Melanie... > If you were really UPSET about asset bloat there wouldn't be years worth > of moaning on the forums about the lack of a way to manage out of control > asset DB size already) > > Now lets examine the advantages and possible simple solutions.. > > * Scripts with the ability to create and modify notecards have > access to a simple persistant data store.. maybe not the most > efficient, but certainly better than > REQUIRING calls to DB operations on a remote server. > > * Scripts with create notecard functions would be able to generate and > distribute customized personalized interaction / audit trails to users > of any interactive device. > ( as a matter of ease of use.... right now this requires > spamming to chat and forcing the user to manually create a notecard and > copy/paste important information ) > > * Its simple ( and hopefully already coded) to implement throttles on > functions in relation to the services they require... SL has a host of > web protocol functions that are limited by calls per timeframe > > I'm not going to argue that all SEVERE threat labels are wrong.. I am > going to argue that it is important to make the tradeoffs clear and the > default settings SIMPLE to modify/override. > > Having a hard coded threat level in a function that obviously has > different uses for different audiences is WRONG. > It was WRONG to start. It is WRONG to continue adding patch levels on top > of it. > > On Tue, Oct 15, 2019 at 8:23 AM Leal Duarte <mailto:mailto:ajldua...@sapo.pt> > wrote: > >> Just to clarify that blow job refers to early Bronze age, where some >> people job was to blow into fire so to it could reach the temperature to >> melt cooper ore and other elements. >> >> ;) >> >> Ubit >> >> >> On 15-Oct-19 14:49, Melanie wrote: >>> The important things here are: >>> >>> - functions that can now be disabled should retain that option >>> - the defaults we have should be preserved, any sensible change to >> defaults need to allow, not restrict, in order to not break things when >> people load oars >>> - The extra file data should be processed efficiently in order not to >> slow down OSSL >>> There are some functions that never should have seen the light of day, >> like my pet peeve, osAvatarPlayAnimation, added to opensim for the single >> purpose of synchronising a music band. That was before we had NPCs and I >> hate this function still being in the codebase. Imagine you're in a serious >> situation, maybe a business meeting, and someone uses it to play a blowjob >> animation on your avatar! There is nothing the victim can do except log out. >>> Another is osMakeNotecard, with which a script in a tight loop can >> create 10s of thousands of notecard assets. DOS attack, anyone? I may just >> end up making an asset service that uses a database for notecards so they >> can be cleaned up. >>> - Melanie >>> >>> >>> >>> >>> >>> >>> ---- On Tue, 15 Oct 2019 06:06:10 +0000 Mike Higgins <mailto: >> mailto:mailto:m...@kayaker.net> wrote ---- >>> >>> As you noticed with the Linda Kelley scripts, the reason why the LSL >>> function sleeps have been kept in the code is for compatibility with >>> scripts that counted on those delays. So they have to stay in. I believe >>> there are a bunch of OSSL functions that are simply duplication of LSL >>> functions with no sleep, a scripter who cares can use those. So I'm only >>> going to make one change: Add an OSSL function that tests if you can >>> call another OSSL function. It sounds like you would vote for me to move >>> the threat level settings into the osslEnable.ini file so you can adjust >>> some of them down. If nobody else has an opinion that is how I will do >> it. >>> On 10/14/2019 8:53 PM, onefang wrote: >>>> On Tue, 15 Oct 2019 00:02:41 +0100 Leal Duarte <mailto: >> mailto:mailto:ajldua...@sapo.pt> >>>> wrote: >>>> >>>> <snip stuff about try/catch> >>>> >>>>> About adding even more code on top of this, just can say that i would >>>>> (will?) remove all this threat mess once a cleaner way (and a lot >>>>> lighter) is found to keep the needed level of protection.. >>>> I'm happy that people are now seeing that some parts of the OSSL threat >>>> level stuff are a bad idea, and are now considering ways of rolling it >>>> back a bit, or providing work arounds for it. It's encouraging. I >>>> have a fork of Opensim that I call opensim-SC, and one of the main >>>> things I had done so far was my own clean up of the OSSL threat level >>>> mess. I had seen that previously the Opensim devs would stick to >>>> their guns about that, so didn't bother letting the devs know about my >>>> fork. Might be time to come in from the cold. >>>> >>>> One of the first things people notice when using my fork is how much >>>> faster the script engine (still Xengine) is. I managed that by >>>> removing three things from OSSL and LL script functions. One of them >>>> was the call to the threat level checking function for stuff that had >>>> no threat level. Lots of things really didn't need a threat level, >>>> like reading notecards. Another was removing the so called "LPS" >>>> accounting. After careful inspection of the code, I found out that >>>> "LPS" figure was not being calculated properly, and ending up in the >>>> wrong place anyway. All it was actually achieving was slowing things >>>> down. The major speed up I think was the last thing I did, remove >>>> function sleeps. Back in the dim past, over a decade ago, the function >>>> sleeps might have served a useful purpose in saving CPU resources on >>>> Second Life servers. Now they serve no useful purpose, and obviously >>>> just slow things down. Your average smart phone these days is probably >>>> as fast as those ancient SL servers. >>>> >>>> People from three grids have been testing this, and so far only one >>>> script had issues. In Linda Kellie's Boardwalk sim, there are swans >>>> and trains that people can ride, with these script engine speed ups, >>>> they zoom around at ludicrous speed. >>>> >>>> The other major thing I did to the script engine was review the actual >>>> threat levels, and reduce a lot of them. >>>> >>>> A function to tell you if an OSSL function will be allowed is a good >>>> idea, but it should have been there in the first place. The >>>> http://opensimulator.org/wiki/Threat_level crash and recover trick >>>> didn't work on some versions of Opensim. My own work around was to >>>> listen to the DEBUG channel from a separate script in another prim (coz >>>> scripts running in the same prim as the one triggering the error can't >>>> hear the error message), parse the error message, and send a message to >>>> the script that generated it, which would then keep it's own list of >>>> functions it isn't allowed to do. This also didn't work in some >>>> versions of Opensim. So if the proposed idea goes through, there will >>>> be three different methods of checking threat levels, none of which >>>> work in every version of Opensim that is currently in use. >>>> >>>> I'll continue my fork, since there are many other things I'm doing that >>>> Opensim likely wont want, but you are free to have a look and grab >>>> anything of interest. >>>> >>>> https://sledjhamr.org/cgit/opensim-SC/?h=master >>>> >>>>> possible some functions should had been added in first plane (no im >>>>> not talking about dyn textures) >>>>> >>>>> Ubit. >>>>> >>>>> >>>>> On 14-Oct-19 22:04, Melanie wrote: >>>>>> The original intention of the LSL permissions system was to make a >>>>>> script fail catastrophically. Subsequent edits have made it so that >>>>>> using a not allowed function would not crash and stop the script, >>>>>> which was the original, and back then intended, behavior. >>>>>> >>>>>> The history of this is that it should be impossible for a script to >>>>>> detect that it is not running in SL, as an attempt to prevent the >>>>>> creation of multi-grid griefing scripts. >>>>>> >>>>>> The threat of griefing never materialized as the SL griefers proved >>>>>> to be uninterested in OpenSim. >>>>>> >>>>>> Still we're stuck with this legacy. However, as was said, there >>>>>> isn't an obvious "invalid return" for some of the functions and, >>>>>> worse, some don't return a value and expect the user to assume the >>>>>> call has succeded. >>>>>> >>>>>> While I have been, at the start, an opponent of discoverability, >>>>>> I've since changed my mind and I believe a querying function for >>>>>> script permissions is the logical step to take. The internal code >>>>>> is already able to determine permissions from a string version if >>>>>> the osFunction name, exposing that would be quite trivial. >>>>>> >>>>>> Also some "safe" functions that used to be subject to permission >>>>>> checks, aren't anymore. >>>>>> >>>>>> So this gets a +1 from me. >>>>>> >>>>>> The donated xmrEngine, which is now YEngine, also had, at the time >>>>>> it was donated, a try/catch mechanism. I am not aware of how much >>>>>> of that remains after the removal of the extension APIs and the >>>>>> linux-only parts that caused it to become YEngine. However, until >>>>>> it, or it's successor(s) become the standard engine and any engines >>>>>> not able to use try/catch are removed, the API can't really make >>>>>> use of it. >>>>>> >>>>>> - Melanie >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ---- On Mon, 14 Oct 2019 19:42:56 +0000 Haravikk >>>>>> <mailto:mailto:mailto:mailto:open...@haravikk.me> wrote ---- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 14 Oct 2019, at 15:12, dz >>>>>>> <mailto:mailto:mailto:mailto:d...@bitzend.net> wrote: >>>>>>> >>>>>>> just an observation from a casual observer with decades of >>>>>>> software design experience... >>>>>>> >>>>>>> Wouldn't it be more productive to wrap all OSSL function calls >>>>>>> in error handling so the response is "correct" regardless of the >>>>>>> permissions? Adding another seperate function that will ALWAYS >>>>>>> need to be called before any OSSL function just adds bloat, >>>>>>> confusion, and removes any incentive for the problem to be >>>>>>> handled "correctly" (looks at the forum name) OOO ya >>>>>>> nvm… >>>>>> The problem with that is that a default return value may not be >>>>>> distinguishable as an error; for example, for a function that >>>>>> returns a list, an empty list might make sense, but you wouldn't be >>>>>> able to tell if the return was genuinely empty, or the call wasn't >>>>>> allowed. >>>>>> >>>>>> In an ideal world we'd use C# or another language with exception >>>>>> handling, as that's a much cleaner way to handle capturing of >>>>>> recoverable errors. Of course it's also a lot of work. >>>>>> >>>>>> I wonder though, how difficult would it be to expose a minimal >>>>>> version of exception handling to LSL? i.e- a very basic try/catch >>>>>> block (no multiple catch blocks, or catches of specific types, just >>>>>> catch everything)? >>>>>>> On Sun, Oct 13, 2019 at 10:27 AM Mike Higgins >>>>>>> <mailto:mailto:mailto:mailto:m...@kayaker.net> wrote: >>>>>>>> Yeah, there is an example of that crash and recover trick at >>>>>>>> http://opensimulator.org/wiki/Threat_level, at the bottom of the >>>>>>>> page. >>>>>>>> >>>>>>>> I have done that and it works after SPAMMING EVERY AVATAR IN THE >>>>>>>> REGION once. Which is still annoying. >>>>>>>> >>>>>>>> On 10/13/2019 4:25 AM, Michel Beauregard wrote: >>>>>>>>> Its a good idea to have a function that test if a osl function >>>>>>>>> is >>>>>>>> available to a owner in a specific location. >>>>>>>>> For now there is a way to test for osl function scriptwise. A >>>>>>>>> failing >>>>>>>> osl function cause a crash of the event calling it. So what I do >>>>>>>> is on state_entry I call a timer with a fake call to all the OSL >>>>>>>> function(s) to be use in my scripts . If the timer failes it >>>>>>>> means that one or any of the function I need is not allowed . And >>>>>>>> the script simply spell out to the owner of that object that it >>>>>>>> cant be use and abort. So at least it does not repeatedly spam >>>>>>>> the region . >>>>>>>>> I will post an example of the script I use in my user page in >>>>>>>>> opensim if >>>>>>>> you like more detail. >>>>>>>> (http://opensimulator.org/wiki/User:Gimisa) . With your function >>>>>>>> you might be able to detect the failure of the osl function call >>>>>>>> instead of sending it to report inworld and act by sending back a >>>>>>>> message to the script for action. Allowing me to use the reply in >>>>>>>> any way I need instead of using timer failure. >>>>>>>>> hope it helps >>>>>>>>> GiMiSa >>> _______________________________________________ >>> Opensim-dev mailing list >>> mailto:mailto:mailto:Opensim-dev@opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> mailto:mailto:Opensim-dev@opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> mailto:mailto:Opensim-dev@opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > _______________________________________________ > Opensim-dev mailing list > mailto:mailto:Opensim-dev@opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > mailto:Opensim-dev@opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list mailto:Opensim-dev@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
