Section: Environments, Tables, and Troff Macros (7)
Updated: xorg-docs 1.7
X provides mechanism for implementing many access control systems. The sample implementation includes five mechanisms:
Host Access Simple host-based access control. MIT-MAGIC-COOKIE-1 Shared plain-text "cookies". XDM-AUTHORIZATION-1 Secure DES based private-keys. SUN-DES-1 Based on Sun's secure rpc system. Server Interpreted Server-dependent methods of access control
@] adds "keith" from the NIS domain of the local machine, and "ruth" in the "mit.edu" NIS domain. For keith or ruth to successfully connect to the display, they must add the principal who started the server to their .Xauthority file. For example:
xauth add expo.lcs.mit.edu:0 SUN-DES-1 [email protected]
@] This system only works on machines which support Secure RPC, and only for users which have set up the appropriate public/private key pairs on their system. See the Secure RPC documentation for details. To access the display from a remote host, you may have to do a keylogin on the remote host first.:
Except for Host Access control and Server Interpreted Access Control, each of these systems uses data stored in the .Xauthority file to generate the correct authorization information to pass along to the X server at connection setup. MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1 store secret data in the file; so anyone who can read the file can gain access to the X server. SUN-DES-1 stores only the identity of the principal who started the server (unix.hostname@domain when the server is started by xdm), and so it is not useful to anyone not authorized to connect to the server.
Each entry in the .Xauthority file matches a certain connection family (TCP/IP, DECnet or local connections) and X display name (hostname plus display number). This allows multiple authorization entries for different displays to share the same data file. A special connection family (FamilyWild, value 65535) causes an entry to match every display, allowing the entry to be used for all connections. Each entry additionally contains the authorization name and whatever private authorization data is needed by that authorization type to generate the correct information at connection setup time.
The xauth program manipulates the .Xauthority file format. It understands the semantics of the connection families and address formats, displaying them in an easy to understand format. It also understands that SUN-DES-1 uses string values for the authorization data, and displays them appropriately.
The X server (when running on a workstation) reads authorization information from a file name passed on the command line with the -auth option (see the Xserver manual page). The authorization entries in the file are used to control access to the server. In each of the authorization schemes listed above, the data needed by the server to initialize an authorization scheme is identical to the data needed by the client to generate the appropriate authorization information, so the same file can be used by both processes. This is especially useful when xinit is used.
The sample implementation includes several Server Interpreted mechanisms:
IPv6 IPv6 literal addresses hostname Network host name localuser Local connection user id localgroup Local connection group id
Tutoriais de Tecnologia Web