Article

Managing Usability with the TERM Variable

Mats Brymér

If you have applications that use telnet, then upgrading older servers may create problems. A common solution is for a server to have one application, and the user uses a telnet icon with a configuration that is specific for that application. When a larger and more powerful server running several network applications replaces an older application server, the telnet icon may pose a security problem by giving the user access to the additional applications. In this article, I will address five of the many ways to solve this problem.

Solution 1

In the first solution, the user gets one account for each application that he uses. However, this solution creates too many accounts for the administrator to manage. This is not a good alternative because management of access rights to the server would be hard to control. Ideally, one account per user decreases administration and security issues.

Solution 2

A second solution is one user-ID in the server and use the terminal emulators script function to point the user to the right start script. This means that if the user logs on in a different manner, he will get access to the server and end up with a shell prompt.

Solution 3

Another way to solve the problem is to use a shell program menu. A common menu that users access, in which they have a pre-set choice of applications, will also work. Or, the user can have a customized menu with a pre-set choice of applications. However, a common menu might confuse the users, since they will see applications that they can not access. Customized menus cause a large workload for the administrator when the user has to update them.

Solution 4

A dynamic menu can be constructed when the user logs on, depending upon which group the user belongs to. With this solution, the user gets a menu when he logs on. When using solution three or four, you can use standard commercial products in the construction of the menus. However, management of the menus will still cause the same workload as before.

Solution 5

Use the TERM variable in the telnet emulator to control which application to start. When the user logs onto the server, a script starts that will check the TERM variable and start the appropriate script to control the access rights of the user. When the TERM has been set to appl1, then the script startappl1 will start. It will control whether the user belongs to the appl1 group. If the user belongs to the appl1 group, the user will get access to the application. If the user does not belong to the appl1 group, the session will be terminated. The users who do not have access rights to the application will not be able to log on. The logon procedure looks the same as before to the user.

The description that follows is a step-by-step solution to implement an easy migration from several application servers to one large application server. The solution that will be described in this article uses the Reflection terminal emulator, DNS, a group file, a log on script, and three different application scripts. Management will be very easy for the administrator. The users have one user-ID and one password to remember. This will give a better adaptation of the local security policy, since the users will have fewer passwords and user-IDs to remember -- no more cue cards with passwords and user-IDs. The use of the R-command to access the server will not be described here. This solution has not been tested with NIS or NIS+, but it should work in that environment also. If you have a client server environment, the user problem should not occur, since the problem is solved in the client software. The following example of how to configure the DNS has been performed on a Sun Spark 5 with Solaris version 2.6:

DNS

Name          Record type      Lookup

server1       IN A             192.168.58.10
appl1         IN CNAME         server1
appl2         IN CNAME         server1

This enables you to easily move the application to a new server. If the DNS lookup is the same as the application group, it will be easy to take control of the environment. However, this is not a requirement for the solution to work.

Terminal Emulation

For the solution to work, you need to be able to set the TERM variable to a name of your choice in the telnet emulator.

Example Using Reflection

Start Reflection and press “Alt-y”. Doing this will start the command window, where you can write scripts or change parameters. How it will look is shown in Figure 1.

In the command window:
To display all the parameters that are set in the emulator write: v
To change parameters:
set TELNET-TERMINAL "appl1"
set DATACOMM-NODE "appl1"
set WINDOWS-TITLE  "Applikation1"

You can then check for errors with v TELNET-TERMINAL in the command window. It should look like this:

TELNET-TERMINAL "appl1"

To save the changes, choose “File” and “Save as” in the terminal window. Pick an appropriate name, in this case appl1. Exit the command window and do not save it. You will end up with a file named appl1.r2w, which can be placed on the workbench or can be a shortcut on the workbench. There are other terminal emulators that can do this, such as Anita, where you enter under the Config and chose UNIXENV setup. Write the application name.

Groups

To edit the group file, use your favorite editor or the grpadd command. Please refer to the following example:

grpadd –g 600 appl1

The groups that are used in this example are presented below.

Application                   Group name        Gid

Applikation1                  appl1             600
Applikation2                  appl2             692
System administrator          sysuser           200

Scripts

You will need two scripts to log into the application -- the start script and the application script. When the user starts the telnet emulator, it asks the DNS for the the IP address. The login procedure that follows is the same as usual, with username and user-ID. However, instead of starting /bin/sh or any other shell, the script /usr/local/bin/startup will start. The entry in /etc/passwd looks like this:

peter:*:200:600:Peter:export/home/peter:/usr/local/bin/startup

The script startup is described in Listing 1. The /usr/local/bin/startup file decides which application script will start, depending on what has been set in the TERM variable. If a user has an account on the server, but has not an authorized TERM variable, the user will get a message that the choice was not allowed. Information will then be sent to the log file, and the session will be terminated. When TERM is set to appl1, the startappl1 script will start. See Listing 2.

The control of the user belonging to a certain group is performed in an easy manner. Use fgrep to see whether the user belongs to the specified group. The information is presented to you by using the id command. If the control is “true”, the information with the TERM variable and the time will be written to the log file. After this procedure, you can add your own variables that normally exist in the profile, or run an initappl1.sh script for the user. You can then run the start script for the application. If the value is not “true”, then a logpost is created with the error information. Be careful of having one group with the name appl and another group with the name appl1 because the value can become “true” in two cases.

The example script, appl2, has a choice of what menu the user will start in the application. This problem can occur when the application has different start menus, depending on which department the user belongs to in the organization. The control performed is done in the same way as in startappl1. If the user is authorized, the user is then checked towards the config file with user name and start script. If the user is not found in the config file, the information about this session is sent to the log file and the session is terminated. See Listing 3.

The config file for the script contains the user-ID and start program. One example of the config file can be found in Listing 4.

The third choice is to use the same method when the systems administrator accesses the server. See Listing 5. All scripts need to have the mask of 755 to work properly. If the permissions are set more strictly, the scripts won't start for all users and there is no entry in the logfiles. A problem can occur when using the su command to another user. The user has /usr/local/bin/startup as login shell. The tests for applications with the TERM variable are performed, so set the TERM variable before you su to another user. This script helps you to do this because it uses the group-ID and the user-ID to input variables. See Listing 6.

Logging

Each script has its own log files stored in /usr/local/log. The catalog and the log files need to have write access for the other 622 because of the error log entries. If the user doesn't belong to the group, you must get that information. If the user can't write to the log file, the script exits and the user can't log in. You can also log to syslog with logger. See the manpage for your server.

Preparing the Environment

When moving the user from the old server to the new one, you can make a script that will change the start shell and create the user with adduser. This is a way to solve the problem with the startup shell:

# Cut -d":" -f1 /etc/passwd >/tmp/foo

Delete all users that do not use the startup shell. (i.e. root, uucp, ftp.)

#for i in 'cat /tmp/foo'
>do
>usermod -s /usr/local/bin/startup $i
>done

Before you test this, make a copy of /etc/passwd.

Conclusion

This solution works fine for us and it's easy to install. It's a cost-effective way to solve the problem with many applications on one server. For the user of the system, it looks the same as before the upgrade. It uses standard UNIX commands so it should work with any UNIX flavor.

About the Author

Mats Brymér has worked with computers for the last 14 years, first with mainframes. For the last 6 years he's worked as a sysadmin on different UNIX flavors. He currently works for WM-data as a UNIX consultant. He can be reached at: mabry@wmdata.com.