Running Networked Applications

Normally, all the applications on your system 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 on another machine saves computing cycles on your local machine, and gives you access to an entire network of applications.

This section describes how to run an application on a remote machine and display it on your local screen. See "More About Security" for additional information on the complexities of running networked applications.

Note - The process for running a networked application in your computing environment might vary.

Using `rlogin` to Run a Networked Application

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.

Contact your system administrator if you do not understand these requirements.

To run a networked application on a remote machine, set your environment variables with the following values.

Set the DISPLAY environment variable in your shell on the remote machine to your local screen.
Enable the remote machine to display the application program on your local machine. To enable this display access on the local machine, use the xhost command:
$ xhost +remote_machine_name

The following procedure describes how to run an application on a remote machine with the rlogin command.

How to Run an Application on a Remote Machine

Use the xhost command on the local machine to give the remote machine display access.
starbug$ xhost + venus

Log in to the remote machine.

starbug$ rlogin venus -l user2
Password: 
Last login: Wed Nov  1 16:06:21 from starbug
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002

Set the DISPLAY variable to the local machine.
venus$ DISPLAY=starbug:0.0

Export the DISPLAY variable to the local machine.
venus$ export DISPLAY

Run the application.
venus$ bigprogram &

Even though you interact with this application just as you would with any other application on your screen, the application runs on the remote machine.

The benefit from running an application in this way is that it uses fewer computing resources than an application that is installed on your machine. This example shows how to run any remote application to which you have access.

More About Security

This section describes some fundamentals of network security that you might find useful as you run applications across the network, including:

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

Who Should Read this Section

You do not need to change the default security configuration in the Solaris operating environment, at minimum, unless you run applications on a remote server.

Access Control Mechanisms

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 other clients 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 129.144.152.193 
   port 3485	Auth name: MIT-MAGIC-COOKIE-1

Two different types of access control mechanisms are used: user based and host based. That is, one mechanism grants access to a particular user's account, while the other mechanism grants access to a particular host, or machine. Unless the -noauth option is used with Xsun, both the user-based access control mechanism and the host-based access control mechanism are active. For more information see "Manipulating Access to the Server".

User-Based Access

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.

Host-Based Access

A host-based mechanism is a general-purpose mechanism. This type of mechanism enables you to give access to a particular host, in which all users on that host can connect to the server. A host-based mechanism is a weaker form of access control. If the 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.

Note - Relink clients that are linked with older versions of Xlib or libcps to enable them to connect to the server with the new user-based access control mechanism.

Authorization Protocols

Two authorization protocols are supported in this version of the Solaris operating environment: MIT-MAGIC-COOKIE-1 and SUN-DES-1. They differ in the authorization data used. The protocols are similar in the access control mechanism used. The MIT-MAGIC-COOKIE-1 protocol that uses the user-based mechanism is the default in the Solaris operating environment.

`MIT-MAGIC-COOKIE-1`

The MIT-MAGIC-COOKIE-1 authorization protocol was developed by the Massachusetts Institute of Technology. At server startup, 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.

`SUN-DES-1`

The SUN-DES-1 authorization protocol, developed by Sun Microsystems, is based on Secure Remote Procedure Call (RPC) and requires Data Encryption Standard (DES) 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. No other user can use your machine-independent netname to access a server, but another user can use the magic cookie to access a server.

This protocol is available only in libraries in the Solaris 1.1 and compatible environments. Any applications built with static libraries cannot use this authorization protocol.

"Allowing Access When Using SUN-DES-1" describes how to allow another user access to your server by adding that person's netname to your server's access list.