Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
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:
Additionally, like every other network connection, tunneling can be used.
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.
The cookie-based authorization methods are based on choosing a magic cookie (an arbitrary piece of data) and passing it to the X display server when it is started; every client that can prove having knowledge of this cookie is then authorized connecting 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 run a program 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. The environment variable XAUTHORITY can be defined to override the name and location of that cookie file.
Hub AI
X Window authorization AI simulator
(@X Window authorization_simulator)
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:
Additionally, like every other network connection, tunneling can be used.
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.
The cookie-based authorization methods are based on choosing a magic cookie (an arbitrary piece of data) and passing it to the X display server when it is started; every client that can prove having knowledge of this cookie is then authorized connecting 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 run a program 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. The environment variable XAUTHORITY can be defined to override the name and location of that cookie file.