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
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.
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.
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:
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
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:
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.
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.
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:
If this command returns a list of machines that still
have permission to use your display, run the following
command to deactivate the permissions:
This command eliminates access to your display for any machines you may have configured earlier.
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:
Note that each line starts with a
display name in the following format:
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,
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
xauth extract - boston:0|rcmd tusconey /usr/bin/X11/xauth merge -