World: r3wp

CONTEXT catching RETURN and EXIT is error #520.

Sorry, #539

An R3 suggestion.....

-- Ability to execute HALT, QUIT etc should be controlled by SECURE

-- DO should have a refinement DO/SECURE ... meaning the DOne thing 
cannot change any SECURE settings
That would be a big step towards safer sandboxing.
-

what I mean is this:

catch/all [
	context load %file.r
]

this has to be completely 100% bullet proof.

where you can replace 'CONTEXT by any of the control/eval funcs

Look at the #1520 proposal, with the clarifying comments. Combined 
with TRY it should catch everything short of an interpreter crash.

We want the separate TRY in order to distinguish between errors and 
unwinds.

Sunanda, SECURE isn't scoped, it is "from now on". You need user 
permission to undo it. If we did this with SECURE we wouldn't be 
able to quit our own apps.

maybe we could start thinking about using a new word for what we 
are talking about extending CATCH to do... its starting to look like 
a long list of groceries for a single word.


reading Andreas' notes on 'CATCH I agree that it should only manage 
throws.  

/all  should mean catch any named or unnamed throw


/quit /unwind and other proposals should fall into another function.

something like 'SANDBOX

CATCH is a sandbox already, just not a very good one. SANDBOX would 
need to be mezzanine because it would need to provide wrapper functions 
as well. And we need the subtle differences in the various CATCH 
options for different circumtannces.

Ah, a SANDBOX function sounds like a good idea.

well, I'd argue that its meant to do exception handling on ERROR!

I think we should even remove its /quit refinement.

Then we could get rid of CATCH/quit and move it to SANDBOX and also 
move the desired CATCH/all to SANDBOX.

well, catch/all for should be just to catch any and all throws... 
no?

That's what CATCH already does at the moment.

CATCH/all would also catch BREAK, CONTINUE, and dynamic RETURN and 
EXIT.

SANDBOX would need to be mezzanine. CATCH/quit and CATCH/all need 
to be native, whatever functions they are in. That means that SANDBOX 
would use CATCH/all, but not be able to implement it.

brian  I don't agree... all of that whould be a separate function. 
 its a different level of failure control.

I don't think it's important whether SANDBOX is mezz or not.

I don't care if it is a separate function, I am just using those 
names for the concept. There are practical reasons to put these in 
CATCH, but it's not strictly necessary. But SANDBOX would *have to 
be mezzanine* to be able to do its job, so we need native functions 
or options for it to call.

The point is not polluting CATCH with options that are better placed 
elsewhere.

yes my point to.

why would sandbox *have* to be mezz?

(btw, I'm not arguing , I really wondering what's the difference)

But they're not better placed elsewhere. CATCH already has the code 
in it to do this task. Putting it elsewhere would mean moving that 
code to an internal function that CATCH calls. Not a bad thing, really, 
but that is the practical reason. Also, we don't want to polute the 
namepace in lib with too many predefined words that could be better 
used for other functions.

Maxim, the reason that SANDBOX would need to be mezz is because there's 
more to sandboxing than catching stuff. You also have to set up a 
context full of safe functions for the sandboxed code to use, including 
wrapper functions. That is mostly mezz work. We don't want to waste 
the word SANDBOX on anything less than that.

ok, good point.  this even adds some strength to my extension module 
  /pre   wish for allowing exported words not to be overwritten by 
standard mezz code.

That is the general module override policy, yes.

no brianh... I don't want the actuall default mezz code to be used 
*at all* I want my version to be become the standard mezz used by 
system.

That is the general module override policy, yes.

no, how I see it is that currently,  if I define 'SANDBOX, export 
it, any mezz code using sandbox will not be using my version... but 
the one within the mezz module.

That is why I had trouble understanding your request at first. What 
you were requesting was already the override policy: first come, 
first served.

since it would redefine the 'SANDBOX function... unless I'm totally 
missing how modules bind stuff.

Sandboxing would require replacing the DO* and MAKE-MODULE* intrinsics 
for the sandboxed code as well. However, *you* would need the non-sandboxed 
mezz functions to *implement* the sandboxed functions.

Embedded extensions with the premezz option would necessarily not 
be useful for making sandboxes. Replacing the mezz code with your 
own mezz code is as simple as replacing the mezz code with your own 
mezz code - no embedded extensions necessary.

But still, mezz code shouldn't override premezz-defined words, because 
that would violate the standard override rules (don't, unless doing 
so explicitly).

but the mezz code won't be using my version since it's also definint 
the same word... for example (algo code, not explicitely working 
r3 code):

; pre-mezz exported
my-func: does [print "a"]

mezz: mezz-module [ 
	my-func: does [print "b"]
	print-my-func: does [my-func]
]

this is what I expect to happen:

>> mezz/print-my-func
== "b"

but I want(need)
== "a"


now I'm not toally clear on how the mezz is being defined, (a do 
block, a module, a contex, whatever) but it woudn't make a difference, 
AFAIK.

DO/SECURE ... thanks for the clarification. Brian.


What could be quite useful then, would be DO/SECURE having a parameter 
block of SECURE settings. But it can only tighten existing SECURE 
settings, not loosen them.


The DONE thing would execute under the tighter policies; and they 
would revert when it exited/returned/quit/crashed etc.

That would be a very useful tool for creating sandboxes.

I agree sunanda, restrict file reading to a specific directory when 
loading application plugins, for example..

Maxim, you do realize that the premezz option for embedded extensions 
isn't implemented yet, right? So how it is done right now doesn't 
matter. When it is implemented it will follow the standard policy 
:)

That is why I got confused by your request: I thought you were asking 
for something different from what we were going to do anyways.

well, the above shows that what I wan't can't be done in the *current* 
standard policy... how would get  == "b" right now?

Explicit override of a module/extension loaded after the standard 
mezz.

in any case, my request made explicit what IMHO needs to be done... 
it wasn't very obvious from the original idea.

of a -> in a

we'll see when it gets done... and I'll be the first in line to test 
it   ;-)

SECURE is a mezz in R3, so DO/secure would need to be implemented 
in the intrinsic DO*. But It might be better to add as a SECURE option 
instead.

Right now SECURE is self-contained. If you make DO* implement DO/secure 
that would make DO* less replacable. If you implement it as SECURE/do, 
it would be easier to do without breaking SECURE's security.

maybe the policy system on which secure is run could use a stack... 
so that we could do secure/push  secure/pop style pairs.