Running remote programs

Granting access to specific accounts

If you log in through scologin, you can control display access by using an authorization protocol called MIT-MAGIC-COOKIE. If scologin's authorize configuration resource is set, upon logging in, both the X server and the user receive an authorization code called a ``magic cookie''. If a user attempts to run a client on an X server but does not have the required authorization record, the server denies the client access. For details on configuring scologin, see ``Customizing scologin'' and the scologin(XC) manual page.

The user receives the magic cookie through an authorization file in the $HOME directory, named .Xauthority. The authorization file may contain authorization codes for multiple X servers, allowing the user to run clients on these servers. For security, only the user has read or write permissions on authorization files. The user that logged in through scologin can share authorization records with other users, however.

NOTE: Host access permissions override user authorization restrictions. If the host machine has obtained access permission through one of the /etc/Xn.hosts files or the xhost utility, any user on the host can access the display without having the X server's authorization code. See ``Granting access to specific hosts'' for more information on /etc/Xn.hosts files and the xhost utility.

To grant access permission to a specific user, perform the following steps. You must be logged in as root to perform this task.

Edit the /etc/Xn.hosts files and remove any host names listed.
Configure scologin so it runs the X server with the magic cookie authorization protocol. The /usr/lib/X11/scologin/Xconfig file must contain the following resource specification:
```
   DisplayManager*authorize: true
```
When you have finished, restart scologin.
Log in through the scologin window.
Run xhost to make sure no other host access permissions exist for your session. (For example, host permissions may be specified in $HOME/.startxrc.) If any host does have access permission, remove the permission with the following command:

xhost -
To make sure your authorization file includes an authorization record for the X server, run the following command:

xauth list
Extract the X server's authorization code by running:

xauth extract tempfilename display
In this command, tempfilename is a temporary file in which the authorization code is stored before it is merged. The displayname is the name of the display as shown by the previous xauth list command.
Finally, merge it with the other user's authorization file by running:

xauth merge tempfilename
In this command, tempfilename is the same temporary file created by the xauth extract command.

Step 1: Disabling system-wide display access

The X server only employs its authorization protocol if all host access is disabled. Because the X server obtains a list of authorized hosts each time it starts, make sure the server provides no initial access permissions.

To disable initial host access, edit the /etc/Xn.hosts file that corresponds to your display. The /etc/Xn.hosts files determine which host machines have access to the X server, regardless of who starts the server. For example, to remove initial access permissions for local display :0, remove all host names from /etc/X0.hosts.

Make sure xhost is not executed automatically from your $HOME/.startxrc file or from a file in your $HOME/.odtpref directory.

Step 2: Configuring scologin

The X server authorization protocol is only used if you log in through the display manager, scologin. scologin must be configured to run your X server with the authorization protocol. The authorization protocol is not used if you start the X server by running startx(X), xinit(X), or Xsco(X).

To configure scologin for authorization, you must edit the /usr/lib/X11/scologin/Xconfig file. However, if scologin is already running on your system, you must stop it before you edit the Xconfig file. As root, use the scologin administration script to do this:

/etc/scologin stop

NOTE: This script shuts down all scologin processes on your system, which results in the closure of any Graphical Environment sessions running at that time. You should notify users before you actually stop scologin.

Now you can edit the /usr/lib/X11/scologin/Xconfig file and verify that the scologin authorize resource is set to true. If this resource specification is not yet defined, add the following line to the Xconfig file:

DisplayManager*authorize: true

DisplayManager*displayname*authorize: true

In almost all circumstances, the first resource specification is suitable. Only use the latter syntax if you want specific X servers to use the magic cookie protocol. For details on setting scologin configuration resources, see the scologin(XC) manual page.

If you want to authorize access for a display other than the one scologin manages by default (/dev/tty02), modify the /usr/lib/X11/scologin/Xservers file to configure the desired X server and tty on which you want the server to run. See ``Running scologin with the Xservers file'' for information on how to do this.

Now you can start scologin, using the scologin administration script. As root, run the following command:

/etc/scologin start

If you want to store your authorization records in a file other than $HOME/.Xauthority, add a line to your .login file that sets the $XAUTHORITY environment variable to the desired filename.

Step 3: Logging in through scologin

Log in through the scologin window. scologin generates a random authorization code and passes it to the server. Your user account also receives the authorization record in the authorization file in your $HOME directory. By default this file is named .Xauthority.

Step 4: Disabling user-defined display access

If you personally configured access to your display for remote machines using the xhost utility, you should disable this access.

You can examine the current host permissions, to see if any access is still permitted with the following command:

xhost

If this command returns a list of machines that still have permission to use your display, run the following command to deactivate the permissions:

xhost -

This command eliminates access to your display for any machines you may have configured earlier.

Step 5: Sharing authorization records with other users

To allow other users to access your display, transfer the authorization record that scologin generates for your X server from your $HOME/.Xauthority file into the $HOME/.Xauthority file of the other users.

Although it is easy to give other users copies of your $XAUTHORITY file, this practice is not recommended, especially if the file needs to be transferred over a network. Preferred practice is to run xauth to extract the authorization record for a specific display and merge it into another user's authorization file.

First, list the servers for which you have authorization by running the following command:

xauth list

Note that each line starts with a display name in the following format:

hostname:display_number

To extract the authorization record, run the following command:

xauth extract tempfile displayname

Be sure displayname matches the string displayed by the xauth list command. tempfilename is a file that you and other users have agreed to use.

If the other users are going to merge the authorization record into their authorization files themselves, be sure to set tempfilename's permissions so that the other users can access it.

The other users can now merge the authorization record in tempfilename into their own authorization files, or you can do it for them as root, with the following command:

xauth merge tempfilename

When the other users have merged the authorization record into their authorization files, delete tempfilename.

If you do not want to create the temporary file, tempfilename, you can use a pipe to redirect the authorization record from the xauth extract command to the xauth merge command as follows:

xauth extract - displayname|xauth -f authfile merge -

The dashes in each xauth command cause output to be directed to standard output instead of to a file, and for input to come from standard input instead of from a file. In this case, authfile is the pathname of the other user's authorization file. You must have read and write permission to authfile for this command to work.

You can use a similar command line to share authorization records across the network. For example, if you log in on boston and want to give your server's authorization record to your account on tusconey, execute the following command on boston:

xauth extract - boston:0|rcmd tusconey /usr/bin/X11/xauth merge -