Comments on: Modules, Globals, System object
Just a brief note to help clarify these concepts in R3.0 and how they are related:
| | Modules | let you create an environment (context) for your script or component (extension/plugin of REBOL). A module separates your script variables from system variables as well as from other component variables (just like you may be doing today using large one-of-a-kind objects). This helps prevent accidental redefinition of system functions, objects, and other values. For example, if you wrote system: none, you're script is not going to crash. You will only be affecting your module's definition of system.
|
| | Globals | are really just the "free variables" of your script module. They are no longer global to the system or to any other module. These variables are "collected" into your module context when your module code gets bound. Additional actions such as do %file may bind additional variables to your module. As far as your script is concerned, these are globals. But, in reality, they are only global to your current module.
|
| | System | is a predefined object for accessing information about the system. The subobjects of system actually belong to different modules, and this is a problem for security. So, system is likely to change in some important ways (see prior article)... but there will still be methods for achieving the same results your script may require (such as localizing the error messages or month names, and a lot more.)
|
Note that some of the R2.0 system environment "tricks" may be quite different. For instance, the system/words object no longer exists (because there are no globals, only modules). You can get a similar list for your module, or you can gather the separate words from all installed modules and build your own list. (Although, a script requires special secure attributes to do that.)
6 Comments Comments:
Henrik
17-May-2006 15:27 |
"The subobjects of system actually belong to different modules, and this is a problem for security."
So does it mean, it would be a security breach for a script to ask which module is included in this particular Rebol 3 executable? Or will there be specific methods for such queries? Will one module be able to query another module for capabilities?
Would there be security measures like for file read/write, where you can do something if some kind of module access is attempted? | Brian Hawley
17-May-2006 15:53 |
This looks promising indeed. I especially like the new definition of "global". I hope that you are able to specify restrictions on the kind of changes that would be allowed to exported module words as well, at least changes within their native context made outside of their context, or you would just have the same problem with globals in a different guise.
Would there be any default modules, that have their exported words imported into your script's context by default? Sort of like java.lang.* in Java.
Will the security infrastructure allow module-local permissions? If so, would there be a way to specify security restrictions on importing a module? This might be a way to implement licensing restrictions as well.
Are there going to be inner modules, or will those just be objects? I'd prefer the latter if you could make similar access restrictions on object words - basically make modules be named global objects. | maximo
17-May-2006 16:10 |
although having every component modularized is a step ahead with regards to security, might I suggest where it can be a step backwards?
user-patched functions? (as opposed to script-patched).
I just want to be sure that any of the configuration files we setup, be it user.r or rebol.r (or any new and better mechanism) operate on the true system context?
This way if we increase security in standard functions like read/write/open etc, all modules are bound into using these more secure definitions, and not the usual rebol-defined ones. | James_Nak
18-May-2006 15:58 |
:)
Will the local behavior of variables within functions be the same in 3.0? That is, now we have to be care ful to explicitly clear them or they can retain their prior values. | Marco
18-May-2006 15:58 |
:)
For me it's quiet obscure, perhaps a small schema can explain this better than 1000 words. | Rob Lancaster
19-May-2006 17:41 |
:)
When It comes to creating new dialects and executing commands received from a unsafe/insecure source, the standard advice to programmers is "write a dialect" - then you can be exactly sure about whats going on...
Is it going to be? or would it be possible? To create a new context in Rebol3.0 specifically to run unsecure code in. Once that code has executed and the results have been extracted. The context can be discarded completely with no damage to any thing else...
I.e The unsafe code cannot modify anything outside it's own context....
p.s Part of me thinks it'd be really cool to be capable of specifying which words and functions are in or could be availible to that unsecure context....
I.e. For, If, either, read and write... but not foreach, view, forall... etc cos then I'd know exactly what the unsecure code could be capable of.... |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
