![]() |
![]()
| ![]() |
![]()
NAMEinterp - Create and manipulate Tcl interpreters SYNOPSISinterp subcommand ?arg arg ...? DESCRIPTIONThis command makes it possible to create one or more new Tcl interpreters that co-exist with the creating interpreter in the same application. The creating interpreter is called the parent and the new interpreter is called a child. A parent can create any number of children, and each child can itself create additional children for which it is parent, resulting in a hierarchy of interpreters. Each interpreter is independent from the others: it has its own name space for commands, procedures, and global variables. A parent interpreter may create connections between its children and itself using a mechanism called an alias. An alias is a command in a child interpreter which, when invoked, causes a command to be invoked in its parent interpreter or in another child interpreter. The only other connections between interpreters are through environment variables (the env variable), which are normally shared among all interpreters in the application, and by resource limit exceeded callbacks. Note that the name space for files (such as the names returned by the open command) is no longer shared between interpreters. Explicit commands are provided to share files and to transfer references to open files from one interpreter to another. The interp command also provides support for safe interpreters. A safe interpreter is a child whose functions have been greatly restricted, so that it is safe to execute untrusted scripts without fear of them damaging other interpreters or the application's environment. For example, all IO channel creation commands and subprocess creation commands are made inaccessible to safe interpreters. See SAFE INTERPRETERS below for more information on what features are present in a safe interpreter. The dangerous functionality is not removed from the safe interpreter; instead, it is hidden, so that only trusted interpreters can obtain access to it. For a detailed explanation of hidden commands, see HIDDEN COMMANDS, below. The alias mechanism can be used for protected communication (analogous to a kernel call) between a child interpreter and its parent. See ALIAS INVOCATION, below, for more details on how the alias mechanism works. A qualified interpreter name is a proper Tcl list containing a subset of its ancestors in the interpreter hierarchy, terminated by the string naming the interpreter in its immediate parent. Interpreter names are relative to the interpreter in which they are used. For example, if “a” is a child of the current interpreter and it has a child “a1”, which in turn has a child “a11”, the qualified name of “a11” in “a” is the list “a1 a11”. The interp command, described below, accepts qualified interpreter names as arguments; the interpreter in which the command is being evaluated can always be referred to as {} (the empty list or string). Note that it is impossible to refer to a parent (ancestor) interpreter by name in a child interpreter except through aliases. Also, there is no global name by which one can refer to the first interpreter created in an application. Both restrictions are motivated by safety concerns. THE INTERP COMMANDThe interp command is used to create, delete, and manipulate child interpreters, and to share or transfer channels between interpreters. It can have any of several forms, depending on the subcommand argument:
For example, with code like proc mycontrol {... script} { the standard setting will provide a relative line number for the command somecode and the relevant frame will be of type eval. With frame-debug active on the other hand the tracking extends so far that the system will be able to determine the file and absolute line number of this command, and return a frame of type source. This more exact information is paid for with slower execution of all commands. Note that once it is on, this flag cannot be switched back off: such attempts are silently ignored. This is needed to maintain the consistency of the underlying interpreter's state.
Note that the script will be executed in the current context stack frame of the path interpreter; this is so that the implementations (in a parent interpreter) of aliases in a child interpreter can execute scripts in the child that find out information about the child's current state and stack frame.
Note that the hidden command will be executed (by default) in the current context stack frame of the path interpreter. Hidden commands are explained in more detail in HIDDEN COMMANDS, below.
The command sets the maximum size of the Tcl call stack only. It cannot by itself prevent stack overflows on the C stack being used by the application. If your machine has a limit on the size of the C stack, you may get stack overflows before reaching the limit set by the command. If this happens, see if there is a mechanism in your system for increasing the maximum size of the C stack.
CHILD COMMANDFor each child interpreter created with the interp command, a new Tcl command is created in the parent interpreter with the same name as the new interpreter. This command may be used to invoke various operations on the interpreter. It has the following general form: child command ?arg arg ...? Child is the name of the interpreter, and command and the args determine the exact behavior of the command. The valid forms of this command are:
Note that the script will be executed in the current context stack frame of child; this is so that the implementations (in a parent interpreter) of aliases in a child interpreter can execute scripts in the child that find out information about the child's current state and stack frame.
Note that the hidden command will be executed (by default) in the current context stack frame of child. For more details on hidden commands, see HIDDEN COMMANDS, below.
The command sets the maximum size of the Tcl call stack only. It cannot by itself prevent stack overflows on the C stack being used by the application. If your machine has a limit on the size of the C stack, you may get stack overflows before reaching the limit set by the command. If this happens, see if there is a mechanism in your system for increasing the maximum size of the C stack. SAFE INTERPRETERSA safe interpreter is one with restricted functionality, so that is safe to execute an arbitrary script from your worst enemy without fear of that script damaging the enclosing application or the rest of your computing environment. In order to make an interpreter safe, certain commands and variables are removed from the interpreter. For example, commands to create files on disk are removed, and the exec command is removed, since it could be used to cause damage through subprocesses. Limited access to these facilities can be provided, by creating aliases to the parent interpreter which check their arguments carefully and provide restricted access to a safe subset of facilities. For example, file creation might be allowed in a particular subdirectory and subprocess invocation might be allowed for a carefully selected and fixed set of programs. A safe interpreter is created by specifying the -safe switch to the interp create command. Furthermore, any child created by a safe interpreter will also be safe. A safe interpreter is created with exactly the following set of built-in commands: after append apply array binary break catch chan clock close concat continue dict eof error eval expr fblocked fcopy fileevent flush for foreach format gets global if incr info interp join lappend lassign ledit lindex linsert list llength lrange lrepeat lreplace lsearch lseq lset lsort namespace package pid proc puts read regexp regsub rename return scan seek set split string subst switch tell time trace unset update uplevel upvar variable vwait while zlib The following commands are hidden by interp create when it creates a safe interpreter: cd encoding exec exit fconfigure file glob load open pwd socket source unload zipfs These commands can be recreated later as Tcl procedures or aliases, or re-exposed by interp expose. The following commands from Tcl's library of support procedures are not present in a safe interpreter: auto_exec_ok auto_import auto_load auto_load_index auto_qualify unknown Note in particular that safe interpreters have no default unknown command, so Tcl's default autoloading facilities are not available. Autoload access to Tcl's commands that are normally autoloaded: auto_mkindex auto_mkindex_old auto_reset history parray pkg_mkIndex ::pkg::create ::safe::interpAddToAccessPath ::safe::interpCreate ::safe::interpConfigure ::safe::interpDelete ::safe::interpFindInAccessPath ::safe::interpInit ::safe::setLogCmd tcl_endOfWord tcl_findLibrary tcl_startOfNextWord tcl_startOfPreviousWord tcl_wordBreakAfter tcl_wordBreakBefore can only be provided by explicit definition of an unknown command in the safe interpreter. This will involve exposing the source command. This is most easily accomplished by creating the safe interpreter with Tcl's Safe-Tcl mechanism. Safe-Tcl provides safe versions of source, load, and other Tcl commands needed to support autoloading of commands and the loading of packages. In addition, the env variable is not present in a safe interpreter, so it cannot share environment variables with other interpreters. The env variable poses a security risk, because users can store sensitive information in an environment variable. For example, the PGP manual recommends storing the PGP private key protection password in the environment variable PGPPASS. Making this variable available to untrusted code executing in a safe interpreter would incur a security risk. If extensions are loaded into a safe interpreter, they may also restrict their own functionality to eliminate unsafe commands. For a discussion of management of extensions for safety see the manual entries for Safe-Tcl and the load Tcl command. A safe interpreter may not alter the recursion limit of any interpreter, including itself. ALIAS INVOCATIONThe alias mechanism has been carefully designed so that it can be used safely in an untrusted script which is being executed in a safe interpreter even if the target of the alias is not a safe interpreter. The most important thing in guaranteeing safety is to ensure that information passed from the child to the parent is never evaluated or substituted in the parent; if this were to occur, it would enable an evil script in the child to invoke arbitrary functions in the parent, which would compromise security. When the source for an alias is invoked in the child interpreter, the usual Tcl substitutions are performed when parsing that command. These substitutions are carried out in the source interpreter just as they would be for any other command invoked in that interpreter. The command procedure for the source command takes its arguments and merges them with the targetCmd and args for the alias to create a new array of arguments. If the words of srcCmd were “srcCmd arg1 arg2 ... argN”, the new set of words will be “targetCmd arg arg ... arg arg1 arg2 ... argN”, where targetCmd and args are the values supplied when the alias was created. TargetCmd is then used to locate a command procedure in the target interpreter, and that command procedure is invoked with the new set of arguments. An error occurs if there is no command named targetCmd in the target interpreter. No additional substitutions are performed on the words: the target command procedure is invoked directly, without going through the normal Tcl evaluation mechanism. Substitutions are thus performed on each word exactly once: targetCmd and args were substituted when parsing the command that created the alias, and arg1 - argN are substituted when the alias's source command is parsed in the source interpreter. When writing the targetCmds for aliases in safe interpreters, it is very important that the arguments to that command never be evaluated or substituted, since this would provide an escape mechanism whereby the child interpreter could execute arbitrary code in the parent. This in turn would compromise the security of the system. HIDDEN COMMANDSSafe interpreters greatly restrict the functionality available to Tcl programs executing within them. Allowing the untrusted Tcl program to have direct access to this functionality is unsafe, because it can be used for a variety of attacks on the environment. However, there are times when there is a legitimate need to use the dangerous functionality in the context of the safe interpreter. For example, sometimes a program must be sourced into the interpreter. Another example is Tk, where windows are bound to the hierarchy of windows for a specific interpreter; some potentially dangerous functions, e.g. window management, must be performed on these windows within the interpreter context. The interp command provides a solution to this problem in the form of hidden commands. Instead of removing the dangerous commands entirely from a safe interpreter, these commands are hidden so they become unavailable to Tcl scripts executing in the interpreter. However, such hidden commands can be invoked by any trusted ancestor of the safe interpreter, in the context of the safe interpreter, using interp invoke. Hidden commands and exposed commands reside in separate name spaces. It is possible to define a hidden command and an exposed command by the same name within one interpreter. Hidden commands in a child interpreter can be invoked in the body of procedures called in the parent during alias invocation. For example, an alias for source could be created in a child interpreter. When it is invoked in the child interpreter, a procedure is called in the parent interpreter to check that the operation is allowable (e.g. it asks to source a file that the child interpreter is allowed to access). The procedure then it invokes the hidden source command in the child interpreter to actually source in the contents of the file. Note that two commands named source exist in the child interpreter: the alias, and the hidden command. Because a parent interpreter may invoke a hidden command as part of handling an alias invocation, great care must be taken to avoid evaluating any arguments passed in through the alias invocation. Otherwise, malicious child interpreters could cause a trusted parent interpreter to execute dangerous commands on their behalf. See the section on ALIAS INVOCATION for a more complete discussion of this topic. To help avoid this problem, no substitutions or evaluations are applied to arguments of interp invokehidden. Safe interpreters are not allowed to invoke hidden commands in themselves or in their descendants. This prevents them from gaining access to hidden functionality in themselves or their descendants. The set of hidden commands in an interpreter can be manipulated by a trusted interpreter using interp expose and interp hide. The interp expose command moves a hidden command to the set of exposed commands in the interpreter identified by path, potentially renaming the command in the process. If an exposed command by the targeted name already exists, the operation fails. Similarly, interp hide moves an exposed command to the set of hidden commands in that interpreter. Safe interpreters are not allowed to move commands between the set of hidden and exposed commands, in either themselves or their descendants. Currently, the names of hidden commands cannot contain namespace qualifiers, and you must first rename a command in a namespace to the global namespace before you can hide it. Commands to be hidden by interp hide are looked up in the global namespace even if the current namespace is not the global one. This prevents children from fooling a parent interpreter into hiding the wrong command, by making the current namespace be different from the global one. RESOURCE LIMITSEvery interpreter has two kinds of resource limits that may be imposed by any parent interpreter upon its children. Command limits (of type command) restrict the total number of Tcl commands that may be executed by an interpreter (as can be inspected via the info cmdcount command), and time limits (of type time) place a limit by which execution within the interpreter must complete. Note that time limits are expressed as absolute times (as in clock seconds) and not relative times (as in after) because they may be modified after creation. When a limit is exceeded for an interpreter, first any handler callbacks defined by parent interpreters are called. If those callbacks increase or remove the limit, execution within the (previously) limited interpreter continues. If the limit is still in force, an error is generated at that point and normal processing of errors within the interpreter (by the catch command) is disabled, so the error propagates outwards (building a stack-trace as it goes) to the point where the limited interpreter was invoked (e.g. by interp eval) where it becomes the responsibility of the calling code to catch and handle. LIMIT OPTIONSEvery limit has a number of options associated with it, some of which are common across all kinds of limits, and others of which are particular to the kind of limit.
Note that the callbacks defined by one interpreter are completely isolated from the callbacks defined by another, and that the order in which those callbacks are called is undefined.
Where an interpreter with a resource limit set on it creates a child interpreter, that child interpreter will have resource limits imposed on it that are at least as restrictive as the limits on the creating parent interpreter. If the parent interpreter of the limited parent wishes to relax these conditions, it should hide the interp command in the child and then use aliases and the interp invokehidden subcommand to provide such access as it chooses to the interp command to the limited parent as necessary. BACKGROUND EXCEPTION HANDLINGWhen an exception happens in a situation where it cannot be reported directly up the stack (e.g. when processing events in an update or vwait call) the exception is instead reported through the background exception handling mechanism. Every interpreter has a background exception handler registered; the default exception handler arranges for the bgerror command in the interpreter's global namespace to be called, but other exception handlers may be installed and process background exceptions in substantially different ways. A background exception handler consists of a non-empty list of words to which will be appended two further words at invocation time. The first word will be the interpreter result at time of the exception, typically an error message, and the second will be the dictionary of return options at the time of the exception. These are the same values that catch can capture when it controls script evaluation in a non-background situation. The resulting list will then be executed in the interpreter's global namespace without further substitutions being performed. CREDITSThe safe interpreter mechanism is based on the Safe-Tcl prototype implemented by Nathaniel Borenstein and Marshall Rose. EXAMPLESCreating and using an alias for a command in the current interpreter: interp alias {} getIndex {} lsearch {alpha beta gamma delta} set idx [getIndex delta] Executing an arbitrary command in a safe interpreter where every invocation of lappend is logged: set i [interp create -safe] interp hide $i lappend interp alias $i lappend {} loggedLappend $i proc loggedLappend {i args} { Setting a resource limit on an interpreter so that an infinite loop terminates. set i [interp create] interp limit $i command -value 1000 interp eval $i { SEE ALSObgerror(n), load(n), safe(n), Tcl_CreateChild(3), Tcl_Eval(3), Tcl_BackgroundException(3) KEYWORDSalias, parent interpreter, safe interpreter, child interpreter
|