Melanie wrote:
> However, if the user chooses to disable osFunctions, then that
> should be honored and all osFunctions, including discovery ones,
> disabled.
>
Personally I agree with the statement "if it's disabled, the framework
should not allow OSSL functions to execute" -- I do however disagree
with it failing with an exception, error messages to debug output, and
script error icons while at the same time not providing any way for a
script creator to pro-actively prevent that error in the first place.
The "Disabled" threat level is an interesting idea.
Teravus Ovares wrote:
> Heh, if this gets enabled by default, I'll probably be the first one
> to set it to false in my OpenSim.ini. Think osConsole
I don't think anyone is suggesting that we enable all osFunctions by
default, and certainly not osConsole. I am not even necessarily
suggesting that we enable any functions by default, other then the ones
that allow a script creator to query and determine if they are allowed
to execute a particular function prior to calling it and having it
possibly fail with an exception being thrown.
Frisby, Adam wrote:
> A simple bool probably isn't enough.
>
> Let's enable an ENUM with the current ThreatLevel, plus maybe a second
> function which returns a bool , "bool isFunctionAvailible("osWhatever");",
> the latter ties in with extensible OSSL via Commanders (not enabled now, but
> in the future it could be).
The original proof of concept patch, provided functions for all of the
following:
* Is OSSL Enabled?
* What threat level is enabled?
* What's the threat level of a particular function?
* Am I currently allowed to execute a particular function?
The proof of concept placed no security on these functions, so that they
would always be available. I can see Melanie's point of view, that an
administrator of a region should have a way to completely and totally
disable the OSSL function library -- and when it's disabled it should
not allow compilation, or execution of any script containing OSSL. I
have some ideas that could enforce both of those, but they would require
more extensive modification of OSSL, and should accompany extension of
OSSL to support functions provided by region modules.
I believe that the default, should be something that fosters the use of
OSSL functions that pose little to no security or resource threats, and
allow creators to use OpenSim to it's full potential. I'll rework my
proposal over the next few days, to attempt to address some of the
concerns that have been raised.
Are there any particular comments regarding implementation?
To allow an isFunctionAvailible() or isFunctionPermissible() or similar,
requires being able to determine a function's threat level and
permissions prior to actually calling it, thus requiring some form of
registration ahead of time. We already register permissions for
specific functions when we add them directly to the OpenSim.ini file.
We could add all functions along with their threat levels to the ini
file, which would allow region administrators to redefine those threat
levels themselves.
My original proposal added C# method attributes, so that methods could
be tagged at compile time with their threat level and then that threat
level could be looked up via reflection at run time. There is some
expense involved in using reflection, but this can be mitigated by
caching the result of the lookup in a Dictionary<>.
A third method would be to require all methods to be registered in much
the same way console commands are registered.
Thoughts? Suggestions?
--
Michael Cortez
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
