Exploring Expect

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 ...