Attaching and Initialising the Interface

6.3 Attaching and Initialising the Interface

A Note on Security

To use the interface, the Tcl program needs to be attached to the ECLⁱPS^e program. The attach request is initiated on the ECLⁱPS^e side, by calling the predicate remote_connect/3 ² from ECLⁱPS^e. The Tcl program is then attached to the ECLⁱPS^e program by executing the procedure ec_remote_init from Tcl. If no error occurs, then the connection is established and the interface is set up.

In more detail, the ECLⁱPS^e predicate remote_connect/3 establishes a socket listening for the connection from the Tcl side. It prints out, on the stream log_output, the hostname and the port number that the Tcl side should connect to:

[eclipse 1]: remote_connect(Host/Port, Control, _InitGoal).
Socket created at address chicken.icparc.ic.ac.uk/25909

On the Tcl side, ec_remote_init is called with the hostname and port number given by remote_connect/3:

ec_remote_init chicken.icparc.ic.ac.uk 25909

ec_remote_init host port ?init_command? ?pass? ?format?: Initialise the remote Tcl interface on the Tcl side. A corresponding remote_connect/3 must have been started on the ECLⁱPS^e side, which specifies the hostname (host) and port number (port) to connect to. The optional init_command is an is a Tcl command that will be invoked at the end of the attachment, before control is handed over to the ECLⁱPS^e side (see section 6.7 for more details). pass and format are optional arguments for a simple security check: they specify an ECLⁱPS^e term that will be matched against a corresponding term (using ==/2 ) on the ECLⁱPS^e side before the connection is allow to proceed (pass will be sent to the ECLⁱPS^e side in EXDR format³; the default is an empty string, which is what remote_connect_setup/3 expects).

If successful, some initial links are established between the two sides, such as the control connection and the connection to allow rpc goals to be sent from the Tcl to the ECLⁱPS^e side. After the attachment, optional user-defined initialisations are performed on both sides (via the InitGoal argument on the ECLⁱPS^e side, and the init_command on the Tcl side), and the two sides can then interact. Initially, the control is given to the Tcl side, and remote_connect/3 returns only when control is handed over to the ECLⁱPS^e side.

As part of the attachment process, the ECLⁱPS^e name of the control connection is passed to the Tcl side. This can be accessed by the user using the command:

ec_control_name: returns the ECLⁱPS^e name of the control connection. An error is raised if this procedure is called before an attachment to ECLⁱPS^e is made.

Unimplemented functionality error will be raised if the Tcl or ECLⁱPS^e side are incompatible with each other. This can happen if one side is outdated, e.g. if the remote Tcl interface used and the ECLⁱPS^e being connected to are not from the same version of ECLⁱPS^e. In this case, it is best to update both sides to the latest version of ECLⁱPS^e.

6.3.1 A Note on Security

Once a Tcl side is attached to an ECLⁱPS^e, the Tcl side can execute ECLⁱPS^e goals on the ECLⁱPS^e side via the ec_rpc mechanism. This may be a security concern as this gives the Tcl side as much access to the resources on the ECLⁱPS^e side as the ECLⁱPS^e process itself, even though the Tcl side can potentially be anywhere reachable from the ECLⁱPS^e side via TCP. However, the connection must be initiated from the ECLⁱPS^e side, and the attachment process must follow a protocol in order for a successful attachment. Nevertheless, if a third party somehow knew which Address to connect to, and follows the protocol, it can ‘steal’ the connection to ECLⁱPS^e. No authentication is performed by the simple remote_connect_setup/3, but remote_connect_accept/6 does allow a simple authentication where it can require the Tcl side to send an ECLⁱPS^e term that matches the one specified in calling the predicate. This is done before the Tcl side is given the ability to run rpc goals on the ECLⁱPS^e side.

It is also possible to limit the remote connection to the same machine as the ECLⁱPS^e process by specifying ‘localhost’ as the host name in the Host/Port address of remote_connect/3. The Tcl side must also use ‘localhost’ for the Host name in its client connection.

Each peer queue is created by creating a new server socket on the ECLⁱPS^e side and then accepting a client connection from the Tcl side. The accept command is told where the client connection is from, and the client host is checked against the client’s host from the attachment, to ensure that the same host has been connected. If not, the ECLⁱPS^e side will reject the particular connection. At this point, the security has probably been compromised, and the two side should disconnect.

Note also that by default, none of the information sent through the queues between the remote side and the ECLⁱPS^e side is encrypted. If the programmer requires these communication channels to be secure, then such encryptions need to be provided by the programmer.

2: Instead of remote_connect/3, the more flexible remote_connect_setup/3 and remote_connect_accept/6 pair of predicates can be used. See the reference manual entries for these predicates for more details.
3: See section 5.8 for more on EXDR format