World Library  
Flag as Inappropriate
Email this Article

X Window authorization

Article Id: WHEBN0003607924
Reproduction Date:

Title: X Window authorization  
Author: World Heritage Encyclopedia
Language: English
Subject: X Window System, Xorg.conf, MIT-SHM, Multi-Pointer X, Xinit
Collection: X Window System
Publisher: World Heritage Encyclopedia

X Window authorization

In the X Window System, programs run as X clients, and as such they connect to the X display server, possibly via a computer network. Since the network may be accessible to other users, a method for forbidding access to programs run by users different from the one who is logged in is necessary.

There are five standard access control mechanisms that control whether a client application can connect to an X display server. They can be grouped in three categories:

  1. access based on host
  2. access based on cookie
  3. access based on user

Additionally, like every other network connection, tunnelling can be used.


  • Host-based access 1
  • Cookie-based access 2
  • User-based access 3
  • Tunneling 4
  • References 5
  • External links 6

Host-based access

The host-based access method consists in specifying a set of hosts that are authorized to connect to the X display server. This system has inferior security, as it allows every user who has access to such a host to connect to the display. The xhost program and three X Window System core protocol requests are used to activate this mechanism and to display and change the list of authorized hosts. Improper use of xhost can inadvertently give every host on the Internet full access to an X display server.

Cookie-based access

The cookie-based authorization methods are based on choosing a magic cookie (an arbitrary piece of data) and passing it to the server when it is started; every client that can prove having knowledge of this cookie is then authorized connection to the server.

These cookies are created by a separate program and stored in the file .Xauthority in the user's home directory, by default. As a result, every program run by the client on the local computer can access this file and therefore the cookie that is necessary for being authorized by the server. If the user wants to start an application from another computer on the network, the cookie has to be copied to that other computer. How the cookie is copied is a system-dependent issue: for example, on Unix-like platforms, scp can be used to copy the cookie.

The two systems using this method are MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1. In the first method, the client simply sends the cookie when requested to authenticate. In the second method, a secret key is also stored in the .Xauthority file. The client creates a string by concatenating the current time, a transport-dependent identifier, and the cookie, encrypts the resulting string, and sends it to the server.

The xauth application is a utility for accessing the .Xauthority file.

User-based access

The user-based access methods work by authorizing specific users to connect to the server. When a client establishes a connection to a server, it has to prove being controlled by an authorized user.

The two methods based on authenticating users using networked identity management systems are SUN-DES-1 and MIT-KERBEROS-5. The first system is based on a secure mechanism of the ONC remote procedure call system developed in SunOS. The second mechanism is based on both client and server trusting a Kerberos server.

A third method is limited to local connections, using system calls to ask the kernel what user is on the other end of a local socket. The xhost program can be used to add or remove localuser and localgroup entries with this method.[1]


Connection between client and server over a network can be protected using a secure tunnelling protocol such as SSL or SSH.


  1. ^ """Server-interpreted Authentication Types "localuser" and "localgroup. X.Org Foundation. Retrieved 16 January 2015. 

External links

  • X security manual page
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.