Perry -- do you have the same basic objection to Safe-TCL that you do do to Java? I would think so.
Safe-TCL comes from a different starting place. For example, the original intent was to actually remove all the dangerous operations such as file manipulation. As Perry's explained, this is different, and better, then just having the run-time "guarantee" that all file I/O is in a "Safe" place.
Uh, no. There is no difference between this and Java. File I/O operations can be added to any Safe-TCL restricted interpreter via "declareharmless". The trusted and untrusted interpreters don't run in separate process spaces, nor is it chrooted(). Perry's criteria is that a failure can not result in the interpreter gaining priveleges it doesn't have. In Safe-TCL this is possible because there is no protection between the trusted and untrusted interpreters. It's possible that a bug could cause the interpreter to use an operating system privelege the model clearly wasn't supposed to have. (e.g., what if, by chance, the restricted and unresstricted interpreter pointers get swapped or given to a function in reverse argument order within an application? Kaboom, the safe-tcl script executes with full priveleges) This is much less secure than Java. First of all, there is no "declareharmless" in Java. The only way to access any low-level I/O in Java is via a class interface, and the "final" keyword on the Java i/o classes prevent any subclasses from overriding these methods. You can not tell the Java runtime to add a new privelege to the interpreter like in Safe-TCL. The only way to extend Java is to create "native" C-code methods and link them in. Java relies on its class loader and byte-code verifier to make sure unauthorized code is attempting execution (such as overriding a system method) It's not as secure as chroot() the Java runtime and running it in a separate process with only a pipe to communicate with the outside O/S, but I feel it is a lot safer than Safe-Tcl. (not to denigrate Safe-TCL, I am using it in a large project, but this is MHO) Finally, all you have to do to remove all I/O ability from Java is delete the File I/O classes from the class hierarchy on your disk where HotJava runs. Most apps don't use any File I/O anyway. (Java forces file i/o to only be allowed in ~/.hotjava or wherever an environment variable points) Java has no built in I/O primitives in the language itself. -Ray