Changing the Default Authorization Protocol
You can change the default authorization protocol, MIT-MAGIC-COOKIE-1, to SUN_DES-1, the other supported authorization protocol, or to no user-based access mechanism at all. You can change the default authorization protocol by editing the Xsun line in the /usr/dt/config/Xservers file. For example, to change the default from MIT-MAGIC-COOKIE-1 to SUN-DES-1, add the -auth sun-des option to the Xsun command by editing the following line in the /usr/dt/config/Xservers file.
:0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -auth sun-des |
If you must run the Solaris operating environment without the user-based access mechanism, add the -noauth option to the Xsun command by editing the following line in the /usr/dt/config/Xservers file.
:0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -noauth |
Caution - By using the -noauth option, you weaken security. It is equivalent to running Solaris software with the host-based access control mechanism only. The server inactivates the user-based access control mechanism. Anyone who can run applications on your local machine is allowed access to your server.
Manipulating Access to the Server
Unless the -noauth option is used with Xsun (see "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. Because 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 that are 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 $HOME directory:
.Xauthority
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 lower the level of security. The server allows access to the host you added, as well as to any user who specifies the default authorization protocol. See "Host-Based Access" or 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 other users can merge the data into their .Xauthority files, thus allowing them access to your server, or to the server to which you connect.
See "Allowing Access When Using MIT-MAGIC-COOKIE-1" for examples of how to use xhost and xauth.
Client Authority File
The client authority file is .Xauthority. It contains entries of the form:
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 might contain the following entries:
anyhost:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75 localhost:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75 anyhost/unix:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75 |
When the client starts, 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 states 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:
unix.userid@NISdomainname |
For example, on host anyhost the .Xauthority file might contain the following entries, where unix.15339@EBB.Sun.COM is the machine-independent netname of the user:
anyhost:0 SUN-DES-1 "unix.15339@EBB.Sun.COM" localhost:0 SUN-DES-1 "unix.15339@EBB.Sun.COM" anyhost/unix:0 SUN-DES-1 "unix.15339@EBB.Sun.COM" |
Note - If you do not know your network name, or machine-independent netname, ask your system administrator.
Allowing Access When Using MIT-MAGIC-COOKIE-1
If you are using the MIT-MAGIC-COOKIE-1 authorization protocol, follow these steps to allow another user access to your server:
On the machine that is running the server, use xauth to extract an entry that corresponds to hostname:0 into a file.
For this example, hostname is anyhost and the file is xauth.info:
myhost% /usr/openwin/bin/xauth nextract - anyhost:0 > $HOME/xauth.info
Send the file that contains the entry to the user who requests access,
Use an email tool, the rcp command, or some other file transfer method to send the file.
Note - Mailing the file that contains 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 or 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
Note - The auth-data is session-specific. Therefore, it is valid only as long as the server is not restarted.
Allowing Access When Using SUN-DES-1
If you are using the SUN-DES-1 authorization protocol, follow these steps to allow another user access to your server.
On the machine that runs the server, use xhost to make the new user known to the server.
For this example, to allow new user somebody to run on myhost:
myhost% xhost + somebody@
The new user must use the xauth command to add the entry into his or her .Xauthority file.
For this example, the new user's machine independent netname is unix.15339@EBB.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.
userhost% echo 'add myhost:0 SUN-DES-1 "unix.15339@EBB.Sun.COM"' | $OPENWINHOME/bin/xauth
Running Clients Remotely, or Locally as Another User
X clients use the value of the DISPLAY environment variable to get the name of the server to which they should connect.
To run clients remotely, or locally as another user, follow these steps:
On the machine that runs the server, allow another user access.
Depending on which authorization protocol you use, follow the steps outlined in either "Allowing Access When Using MIT-MAGIC-COOKIE-1" or "Allowing Access When Using SUN-DES-1".
Set DISPLAY to the name of the host that runs the server.
For this example, the host is remotehost:
myhost% setenv DISPLAY remotehost:0
Run the client program as shown.
myhost% client_program&