There are three tasks you must perform before you can use remote clients on your display:
This chapter describes how to do each of these tasks.To establish user equivalence on the remote host:
localhost is the name of the machine on which you are running the X server. login is your account name on localhost.
When you have finished, save and exit the file.
For more details on the above network commands,
see Networking Guide.
Setting up access permissions to your display
Before you can display a remote client on your X server,
you must allow the client to access your display.
There are two ways you can control access to your display:
Each method has advantages and disadvantages.
Granting access to a remote host machine
is easy to accomplish, but it provides no control over
which accounts on the remote host are able to access your display.
In systems where security is of greater concern,
it is recommended that you use the authorization code method.
Be aware that the security of a system that uses the authorization
method is only as secure as the user's account;
if anyone else can read the authorization file that contains
the authorization code, they can also access your display.
Also, the authorization code method only works with
X servers that are provided with the Graphical Environment (Xsco) or with
X terminals that support the XDMCP protocol.
Granting access to specific hosts
The X server maintains a list
of machines that have access to the display.
You must establish this list even if you
plan to only grant access to users with an authorization code.
To grant access to your display for specific host machines, perform the following steps.
The access permissions take effect when the X server is restarted.
Each line in the Xn.hosts files consists of just the name of the host machine that has access to the server. For example, to allow any user on boston to access the tusconey:0 display, add the following line to /etc/X0.hosts on tusconey:
bostonYou must be logged in as root to edit these files. The changes you make take effect when the server is restarted.
Note that any user on a host machine specified in these files has access to your display whenever the X server is running. If you only want to grant access to a host for a single X session, do not modify these files. Instead, see Step 2.
In addition to adding hosts to
the Xn.hosts files,
be sure to remove hosts that you do not want to have
access to your display.
Step 2: Setting temporary display access
Once the X server is running, you can examine the current
host permissions with the following command,
from a local scoterm window:
xhost
Use this command on the local machine where the server is running. xhost with no command line options displays a list of machines that currently have access to your display. Use this list to determine if the system-wide configuration provides access to the appropriate host machine.
To add a host to the X server's host access list,
execute the following command:
xhost +hostname
If you omit hostname, the X server removes all access restrictions, allowing any client on any machine on the network to access your display.
If there are hosts configured that you do not want accessing
your X server, remove them from the server's host access
list by running the following command:
xhost -hostname
This command removes hostname
from the host access list.
If you omit hostname,
xhost specifies that no remote host can access
your display for the duration of the current session.
This option is very useful to reverse the
effect of running xhost +.
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.
To grant access permission to a specific user, perform the following steps. You must be logged in as root to perform this task.
DisplayManager*authorize: trueWhen you have finished, restart scologin.
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.
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
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
or
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 -
See also:
If you are using csh,
set the $DISPLAY environment variable with the
following command:
setenv DISPLAY displayname
If you are using sh or ksh,
set the $DISPLAY environment variable with the
following command:
DISPLAY=displayname; export DISPLAY
The displayname specification uses the following
form:
[hostname]:display_number[.screen_number]
hostname specifies the machine on which the display is running and must be either a machine name or the machine's network address, as listed in /etc/hosts. If you omit hostname, the display is presumed to be running locally.
:display_number specifies one of the displays on hostname. Each display on a system is assigned a :display_number, beginning with 0. screen_number specifies the screen on which the display is running.
See also:
Display names are specified in the following form:
[hostname]:display_number[.screen_number]
See ``Running clients with the DISPLAY environment variable'' for more information on how to set displayname.
You can use the above syntax regardless of whether
you are executing the client while logged in to the host
through rlogin or telnet, or
through rcmd.
For example, if you are running the :0 server on boston
and want to run the xclock client
on tusconey, run the
following command from boston:
rcmd tusconey "/usr/bin/X11/xclock -display boston:0" &
Similarly, if you log in to tusconey with rlogin or
telnet, execute the following command:
/usr/bin/X11/xclock -display boston:0 &
Note that in the above cases, the
ampersand (&) runs the client in the background
so that you do not have to close the client to
get your command line back.
You can close the client with the
Window menu or by typing <Alt><F4>.
Example of running a remote client on your display
This section provides a comprehensive example that ties
together many of the concepts and procedures discussed in this
chapter.
For the purposes of this example, let's assume
you have accounts on two
SCO OpenServer machines: one that sits
on your desk, named boston,
and another, named tusconey, that resides in another room.
The two machines are part of the same network,
and their names and IP addresses are listed in each other's
/etc/hosts files.
You have root privileges on boston,
but you do not have root privileges on tusconey.
Your account name is the same on both machines.
You are accustomed to using the clients
installed on boston from the default
server running on tty02.
You just received mail that
on the machine tusconey
there is a nicely-configured version of
the desktop client, xdt3,
and you want to try it out.
This example explains how to:
In this command, username is your login name. When you have finished, save and exit the file. You have established user equivalence on tusconey. You can now log off tusconey.
When you have finished, save and exit the file.
The result is a list of servers for which you have
authorization records. The line beginning with
``boston:0'' indicates that you have authorization
to your local X server.
If the .Xauthority file does not already exist, the following message appears:
/usr/bin/X11/xauthority: creating new authority file username/.XauthorityIn this message, username is your login name.
The line beginning with ``boston:0'' indicates that your account on tusconey has authorization to access your X server.
Note that you are not prompted for a password because you
have user equivalence on tusconey. When you are logged in,
run the following commands:
PATH=:/usr/bin/X11
DISPLAY=boston:0
export DISPLAY PATH
scosession 2>/dev/null &
When the Desktop appears, double-click on the UNIX icon to open a scoterm window. In the window, run hostname to verify that you are using tusconey's filesystem.
When you are done using the Desktop, exit through the File menu.
The preceding steps only apply to your current X session. If you want to make these changes take effect every time you start a session, you must reauthorize your account as shown in Step 11 above. You can do this automatically by placing the command given in Step 11 in the file $HOME/.startxrc.