> From [EMAIL PROTECTED] Mon Oct 1 >04:36:41 2001 > . > . > . > In Tcl, file and TCP socket handling are done by built-in commands, > and libraries can always define new ones. There are variants though > (for assorted embedded environments IIRC) that lack one or both of > them, which is OK since they're not an essential part of the core.
> > * no opcode is even remotely IO-related. The fanciest you can find > > may be the regexp-literal. > Tcl opcodes are not complex at all, and don't do anything with IO. > But then they're not exposed outside the core anyway; programmers only > notice they're there by the increased speed of execution. > But then our security model is based at the Tcl interpreter and > command levels, which seems to work well. For example, IO itself is > typically not a privileged operation, but creating a channel (e.g. by > opening a file or socket) usually is, and these cause a trap out into > the parent interpreter which can decide whether to allow the creation > or throw it out (with optional rude message.) This is, of course, > completely configurable (so it's quite easy to implement file-size > limiting, even though its not there by default.) IIRC, the only > operations that are not restrictable in this way are reading variables > and calling commands (though the set of variables and commands is > controllable.) > I suppose it depends in general on integrating the security model with > the abstraction that the language itself uses. > . > . > . Donal explains things well--Tcl's "safe interpreters", in particular. For those who aren't familiar with Tcl, I'll make a couple of points explicit. Tcl-er's generally say the language does NOT offer a "sandbox"--it has a *better* model, one based on flexible provision of services (com- mands). The claim is that we have more experience with service-management security (think of OSs) than sandbox security, so the former is more reliable.
