Authorization

The network transparency of the X Window System holds special risks. For example, you can dump the contents of any window if you have access to the X Window server. Special security methods are used to restrict the access to an X Window server. There are two classes of methods:

Only X Window clients running on certain machines are allowed to connect to the server (host access control). The server checks the host's network address.

The X Window server examines a key sent by the client during connection setup (e.g. using the MIT-MAGIC-COOKIE-1 mechanism). Normally the key is stored in a file which can be accessed by the user only ($HOME/.Xauthority usually).

The XmetaX proxy transparently supports both classes of access control. However, there are two levels of authorization:

on the one hand the authorization of the X Window clients by the XmetaX proxy

and on the other hand the authorization of the XmetaX proxy by the X Window servers.

Authorization of the X Window clients by the XmetaX proxy

The XmetaX proxy authorizes its clients like an X Window server.

When (re-)initializing, the xmetax program reads the names of the hosts, which are permitted by host access control, from the file /etc/Xdisplay_number.hosts. The display_number corresponds to the client connection (X Window client connection), hence usually 0. Local connections are generally allowed. You may add or delete machines later using the program xhost.

For authorization through a key (the XmetaX proxy supports MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1), the statement

authorization file_name|none

specifies an authorization file, which the XmetaX proxy uses to authorize X Window clients.

However, if there is an authorization file defined through the -auth argument in a serverCommand statement (X Window server), then this file is also used by the XmetaX proxy. Display managers usually append the -auth argument (With a display manager).

A display manager may transmit the authorization key to the xmetax program through the Display Manager Control Protocol (X Display Manager Control Protocol).

The statement

accessControl on|off

switches the authorization of clients generally on (default value) or off.

Authorization of the XmetaX proxy by the X Window servers

The XmetaX proxy must be authorized by the X Window servers like a normal client. If the access to the real X Window servers is unlimited, any access restriction by XmetaX is useless.

For host access control, the name of the machine running the xmetax program must be written into the access file, usually the file /etc/Xdisplay_number.hosts, unless the xmetax program and the X Window server are running on the same machine. The display_number corresponds to the display number of the X Window server (X Window server), hence usually 1 with the proxy, otherwise 0. Using the program xhost, the hostname can be added later when the X Window server is already running.

For key authorization (the XmetaX proxy supports MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1) the file $HOME/.Xauthority and the environment variable $XAUTHORITY are relevant. However they can be overridden by the statement

serverAuthorization file_name|own|none

defining an authorization file, which is used by the XmetaX proxy only for the authorization by the X Window servers, which are started by the proxy, namely through the serverCommand statement (X Window server) or as ressource manager (Resource manager) using one of the options InWindow or DynamicServer.

The parameter own lets the XmetaX proxy generate a random key for authorization by the X Window servers.

If this server side authorization file is not configured, the xmetax program tries to get an appropriate key from the client side (Authorization of the X Window clients by the XmetaX proxy). In general it succeeds if the authorization file is configured by the display manager using the -auth argument. (With a display manager).

Copyright © 2018 X-Software GmbH
info@x-software.com