Exploring Expect: A TCL-Based Toolkit for Automating Interactive Programs

Exploring Expect: A TCL-Based Toolkit for Automating Interactive Programs

by Don Libes
     
 

View All Available Formats & Editions

Written by the author of Expect, this is the first book to explain how this new part of the UNIX toolbox can be used to automate telnet, ftp, passwd, rlogin, and hundreds of other interactive applications. The book provides lots of practical examples and scripts solving common problems, including a chapter of extended examples.See more details below

Overview

Written by the author of Expect, this is the first book to explain how this new part of the UNIX toolbox can be used to automate telnet, ftp, passwd, rlogin, and hundreds of other interactive applications. The book provides lots of practical examples and scripts solving common problems, including a chapter of extended examples.

Editorial Reviews

Booknews
Authored by the creator of Expect, this handbook shows how to use this Tcl-based toolkit to automate telnet, passwd, rlogin and other applications in a UNIX environment. Includes an introduction to Tcl (Tool Command Language), and discussions on glob patterns, debugging patterns, handling multiple processes, and the spawn and send commands. Annotation c. by Book News, Inc., Portland, Or.

Product Details

ISBN-13:
9781565920903
Publisher:
O'Reilly Media, Incorporated
Publication date:
12/28/1994
Series:
Nutshell Handbooks Series
Edition description:
1 ED
Pages:
606
Sales rank:
1,388,770
Product dimensions:
7.00(w) x 9.10(h) x 1.30(d)

Read an Excerpt


Chapter 8: Handling a Process and a User

Security And Insecurity

Quite often, it is possible to automate everything except reading the password. As I explained earlier, the password should not be passed as an argument to a script for security reasons. An alternative to prompting is to embed the password directly in the script. There are two ways to secure such files-by file protection or by host protection. I prefer host protection but I will cover file protection first-if only to make the merits of host protection more obvious.

Securing Scripts By File Protection

Scripts containing passwords should be unreadable to users with normal utilities such as cat and vi. However, such scripts must still be executable. Unfortunately, the UNIX file system has no direct way of creating scripts which are executable but unreadable. On systems which support setgid shell scripts, you may indirectly simulate this as follows:

Create the Expect script (that contains the password) as usual. Make its permissions be 750 (-rwxr-x---) and owned by a trusted group, i.e., a group which is allowed to read it. if necessary, create a new group for this purpose. Next, create a /bin/sh script with permissions 2751 (-rwxr-s--x) owned by the same group as before. The shell script should invoke both Expect and the script name by their absolute pathnames.

The resulting shell script can be run by anyone, and the shell script in turn has permission to run the Expect script which is otherwise unreadable to everyone.

This may seem a little kludgey. In fact, it is worse than that. Storing unencrypted passwords in files is almost always a disaster, and there are usually better ways of getting the same effect. Consider that when the password is stored in your head, it is much easier to update. But once a password is stored in a script, each script containing the password has to be found and changed. Even worse, the scripts are more susceptible (than your brain) to yielding their contents. Consider what might happen if you run out of your office for a bathroom emergency. Someone could walk in, sit down at your workstation, and immediately have complete access to your files including the ones containing passwords. If a hacker steals a backup tape or stumbles onto a root login, all the files on the system can be read along with any unencrypted passwords in scripts.

As if this is not bad enough, the implementation of setuid and setgid scripts is insecure on some UNIX systems. It is often possible to trick such scripts into running a completely different program than the script originally called for. To avoid this problem, you must write a C program that is setuid to invoke the Expect script. To avoid a total breech of security, it is best to avoid root-setuid shell scripts on such systems. The use of a non-root group in the technique described earlier is a reasonable compromise at medium security sites.

A very different problem is that of writing setuid or setgid Expect scripts in the first place. Setuid Expect scripts have many of the same problems as setuid shell scripts. Writing such scripts should be avoided except by very experienced programmers. Examples and explanations of such scripts are beyond the scope of this book. If you are interested in more information on this aspect of scripts, read the Computer Security FAQ frequently posted to the Usenet newsgroup news. answers.

Securing Scripts By Host Protection

As I described in the previous section, it is unwise to depend on the file system to protect passwords embedded in scripts. A better alternative is to depend on the protection of a secure host. Such a host must prevent users who should not read the script from even logging in. In this case, the file protections are irrelevant since the users cannot even get to the file system that holds the file. ideally, the host should be physically secure as well. This means that random users cannot physically access it nor can they walk off with the backup tapes. The host should not even permit root access over the network. Of course, remote mounting should not be permitted. Indeed, all unnecessary daemons should be disabled.

Given a secure host, passwords may be embedded in scripts. If necessary, the scripts can begin by connecting to another host and then performing the desired interaction. Passwords will be available to a network sniffer, of course, but the risk is no greater than from a real person doing the same thing.

Such scripts may be run out of cron, allowing scripts to run programs that normally require passwords to run automatically and at times when no users are available. This is a common problem with databases that collect information that must be processed in the wee hours of the morning.

Scripts may also be run on demand at user request. Although users cannot log in to secure hosts, Expect scripts may be installed as inetd daemons allowing them to be started simply by running telnet with the specific port number or service name. I will describe this further in Chapter 17 (P. 392) with an example demonstrating how to allow users to interact with remote applications that require secret passwords.

Resetting The Terminal Upon Exit

When an Expect script ends, the terminal modes are automatically restored to those that were in effect when the Expect script began. For example, if the script put the terminal into raw mode, the terminal is taken out of raw mode when the script ends. This occurs whether the exit command is called explicitly or the script simply ends.

This makes error handling a little easier especially while debugging. During script development, it is not uncommon to have the script blow up as errors are encountered. By default, when an error occurs, Expect restores the terminal modes and exits. This makes it very easy to recover even from severe errors in the script.

More On The stty Command

Except for stty, all of the non-interactive UNIX programs executed so far have been run by the exec command. Compare:

exec kill -9 $pid
exec cat /etc/motd
exec touch foo
stty raw

It is possible to execute stty via exec on some systems but the required redirection is system dependent. Some stty implementations are sensitive to any redirection of standard error while other implementations require the standard error be redirected in order to catch errors. There is no way to call stty with exec that is both portable and reliable.

Expect addresses this problem by providing a built-in stty that uses the native UNIX stty command with redirection defined appropriately for your system. Additional redirection should be omitted if you want to affect the controlling terminal. For example, the following command disables echoing on the controlling terminal....

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >