This appendix describes an advanced feature of the OpenWindows environment that enables you to run applications that reside on another machine on your network.
Most users do not need to read this appendix. If you want to explore the possibility of running networked applications, you can talk to your system administrator about the special applications that may be available on your network.
Normally in the OpenWindows environment all the applications on your screen (such as Mail Tool and Calendar Manager) are programs that are running on your local machine. However, if your workstation is part of a network, you can run applications on another machine and display them on your local screen. Running an application in this manner saves computing cycles on your local machine, and gives you access to an entire network of applications.
This appendix describes the simplest scenario for running an application on a remote machine and displaying it on your local screen. Because your computing environment may vary, you will need to be flexible in following these instructions. The section "D.2 More About Security" provides additional information on the complexities of running networked applications.
To use the following procedure to run a remote application, you must meet these requirements:
You must have access rights to the remote machine.
Your home directory must be NFS-mountable on the remote machine.
The application and appropriate libraries must be installed on the remote machine, or host.
Contact your system administrator if you do not understand these requirements.
If the OpenWindows libraries have not been installed
in the standard /usr/lib or /usr/local
shared library directories, you must set the
LD_LIBRARY_PATH environment variable to the appropriate directory
Below is an example of running a Command Tool on a remote machine using rlogin. In this example, the home directory is mounted on the remote machine on /home/mydirectory, and the OpenWindows software is located in /usr/openwin on the remote machine. Change the variables, mydirectory and mymachine as appropriate for your arrangement. Also, replace cmdtool, with the name of the application you want to run.
$ rlogin remotemachine . . (The following commands are executed on the remote machine.)] . . $ HOME=/home/mydirectory $ DISPLAY=mymachine:0 $ LD_LIBRARY_PATH=/usr/openwin/lib $ /usr/openwin/bin/cmdtool &
After you enter the last line, a Command Tool window appears on your screen. Even though you interact with this application just as you would with any other application on your screen, the Command Tool application itself is actually running on the remote machine.
Although there is no particular advantage to running a Command Tool in this way (it is already locally available on your machine and does not use a significant amount of your computing resources), this example shows how to run any remote application that may be available to you.
User-based and host-based access control mechanisms
The MIT-MAGIC-COOKIE-1 and SUN-DES-1 authorization protocols
When and how to change a server's access control
How to run applications remotely, or locally as a different user
The default security configuration in the OpenWindows Version 3.3 software, or later versions, does not need to be changed unless you run applications in any of the following configurations:
You run an application that is statically linked to OpenWindows Version 2 libraries and you want to use the SUN-DES-1 authorization protocol.
An access control mechanism controls which clients or applications have access to the X11 server. Only properly authorized clients can connect to the server; all others are denied access, and are terminated with the following error message.
Xlib: connection to hostname refused by server Xlib: Client is not authorized to connect to server
The connection attempt logs to the server console as:
AUDIT: <Date Time Year>: X: client 6 rejected from IP 220.127.116.11 port 3485 Auth name: MIT-MAGIC-COOKIE-1
There are two different types of access control mechanisms: user-based and host-based. (That is, one mechanism grants access to a particular user's account, while the other grants access to a particular host, or machine.) Unless the -noauth option is used with openwin, both the user-based access control mechanism and the host-based access control mechanism are active. For more information see "D.2.4 Manipulating Access to the Server" in this chapter.
A user-based, or authorization-based mechanism allows you to give access explicitly to a particular user on any host machine. The user's client passes authorization data to the server. If the data match the server's authorization data, the user is allowed access.
A host-based mechanism is a general purpose mechanism. It allows you to give access to a particular host, in which all users on that host can connect to the server. This is a weaker form of access control: if that host has access to the server, all users on that host are allowed to connect to the server.
The Solaris environment provides the host-based mechanism for backward compatibility. Applications linked with versions of Xlib or libcps older than OpenWindows Version 2 software or X11R4 do not recognize the new user-based access control mechanism. To enable these applications to connect to the server, a user must either switch to the host-based mechanism, or relink with the newer versions of Xlib and libcps.
If possible, clients linked with older versions of Xlib or libcps should be relinked with newer versions of these libraries to enable them to connect to the server with the new user-based access control mechanism.
Two authorization protocols are supported in this version of the OpenWindows software: MIT-MAGIC-COOKIE-1 and SUN-DES-1. They differ in the authorization data used; they are similar in the access control mechanism used. At any time, the server implements only one protocol. The MIT-MAGIC-COOKIE-1 protocol using the user-based mechanism is the default in the OpenWindows software.
The MIT-MAGIC-COOKIE-1 authorization protocol was developed by the Massachusetts Institute of Technology. At server start-up, a magic cookie is created for the server and the user who started the system. On every connection attempt, the user's client sends the magic cookie to the server as part of the connection packet. This magic cookie is compared with the servers' magic cookie. The connection is allowed if the magic cookies match, or denied if they do not match.
The SUN-DES-1 authorization protocol, developed by Sun Microsystems, is based on Secure RPC (Remote Procedure Call) and requires DES (Data Encryption Software) support. The authorization information is the machine-independent netname, or network name, of a user. This information is encrypted and sent to the server as part of the connection packet. The server decrypts the information, and if the netname is known, allows the connection.
This protocol provides a higher level of security than the MIT-MAGIC-COOKIE-1 protocol. There is no way for another user to use your machine independent netname to access a server, but it is possible for another user to use the magic cookie to access a server.
This protocol is available only in libraries in the OpenWindows Version 3 and later environments. Any applications built with static libraries, in particular Xlib, in environments prior to OpenWindows Version 3 cannot use this authorization protocol.
"D.2.4.3 Allowing Access When Using SUN-DES-1", in this chapter, describes how to allow another user access to your server by adding their netname to your server's access list.
The default authorization protocol, MIT-MAGIC-COOKIE-1, can be changed to SUN_DES-1, the other supported authorization protocol, or to no user-based access mechanism at all. You change the default by supplying options with the openwin command. For example, to change the default from MIT-MAGIC-COOKIE-1 to SUN-DES-1, start the OpenWindows software as follows:
example% openwin -auth sun-des
example% openwin -noauth
Using -noauth weakens security. It is equivalent to running the OpenWindows software with the host-based access control mechanism only; the server inactivates the user-based access control mechanism. Anyone that can run applications on your local machine will be allowed access to your server.
Unless the -noauth option is used with openwin (see "D.2.3.3 Changing the Default Authorization Protocol"), both the user-based access control mechanism and the host-based access control mechanism are active. The server first checks the user-based mechanism, then the host-based mechanism. The default security configuration uses MIT-MAGIC-COOKIE-1 as the user-based mechanism, and an empty list for the host-based mechanism. Since the host-based list is empty, only the user-based mechanism is effectively active. Using the -noauth option instructs the server to inactivate the user-based access control mechanism, and initializes the host-based list by adding the local host.
You can use either of two programs to change a server's access control
mechanism: xhost and xauth. For more
information, see these man pages. These programs access
two binary files created by the authorization protocol. These files contain
session-specific authorization data. One file is for server internal use
only. The other file is located in the user's
Client Authority file
Use the xhost program to change the host-based access list in the server. You can add hosts to, or delete hosts from the access list. If you are starting with the default configuration -- an empty host-based access list -- and use xhost to add a machine name, you will lower the level of security. The server will allow access to the host you added, as well as to any user specifying the default authorization protocol. See "D.2.2.2 Host-Based Access" for an explanation of why the host-based access control mechanism is considered a lower level of security.
The xauth program accesses the authorization protocol data in the .Xauthority client file. You can extract this data from your .Xauthority file so that another user can merge the data into their .Xauthority file, thus allowing them access to your server, or to the server to which you connect.
See "D.2.4.2 Allowing Access When Using MIT-MAGIC-COOKIE-1"for examples of how to use xhost and xauth.
connection-protocol auth-protocol auth-data
By default, .Xauthority contains MIT-MAGIC-COOKIE-1 as the auth-protocol, and entries for the local display only as the connection-protocol and auth-data. For example, on host anyhost, the .Xauthority file may contain the following entries:
anyhost:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75localhost:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75anyhost/unix:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75
When the client starts up, an entry corresponding to the connection-protocol is read from .Xauthority, and the auth-protocol and auth-data are sent to the server as part of the connection packet. In the default configuration, xhost returns empty host-based access lists and state that authorization is enabled.
If you have changed the authorization protocol from the default to SUN-DES-1 the entries in .Xauthority contain SUN-DES-1 as the auth-protocol and the netname of the user as auth-data. The netname is in the following form:
For example, on host, anyhost the .Xauthority file may contain the following entries, where unix.15339@EBB.Eng.Sun.COM is the machine-independent netname of the user:
anyhost:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM" localhost:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM" anyhost/unix:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM"
For this example, hostname is anyhost and the file is xauth.info:
myhost% /usr/openwin/bin/xauth nextract - anyhost:0 > $HOME/xauth.info
Mailing the file containing your authorization information is a safer method than using rcp. If you do use rcp, do not place the file in a directory that is easily accessible by another user.
The other user must merge the entry into his/her.Xauthority file.
For this example, userhost merges xauth.info into the other user's .Xauthority file:
userhost% /usr/openwin/bin/xauth nmerge - < xauth.info
The auth-data is session-specific; therefore, it is valid only as long as the server is not restarted.
For this example, to allow new user somebody to run on myhost:
myhost% xhost + somebody@
For this example, the new user's machine independent netname is unix.15339@EBB.Eng.Sun.COM. Note that this command should be typed on one line with no carriage return. After the pipe symbol, type a space followed by the remainder of the command.
To run clients remotely, or locally as another user, follow these steps:
On the machine running the server, allow another user access.
Depending on which authorization protocol you use, follow the steps outlined in either "D.2.4.2 Allowing Access When Using MIT-MAGIC-COOKIE-1"or "D.2.4.3 Allowing Access When Using SUN-DES-1".
DISPLAY to the name
of the host running the server.
For this example, the host is remotehost:
myhost% setenv DISPLAY remotehost:0