There is several methods of display access control, but the most used are two: Host Access controlled by `xhost` and MIT-MAGIC-COOKIE-1 controlled by `xauth`. Below is just what you can find in man, and may be a little more. Host-based Access control allows to check by - host network address (traditional), - hostname ("server interpreted" entry), - user name ("server interpreted" entry). Checking by network address/hostname effectively allows all users on machine with that address to connect, so is not very useful. Checking by user name is far better, but works only for local connections through Unix Domain socket, because only in that case listening process (X server) can reliable check uid/gid of connecting process (see "Ancillary Messages" in unix(7)). MIT-MAGIC-COOKIE-1 is "shared secret" authentication scheme. Client should provide the same cookie (md5 hash sum, in fact) as X server already knows. Client stores his cookies in $XAUTHORITY file (~/.Xauthority by default). There is possbile to store many cookies in one file: the search key in file is connection family with display number (e.g. "192.168.1.2:5" for remote connection or "hostname/unix:2" for local unix domain socket connection). There is possible to have persistent cookie passed to X server on start with '-auth' option or generate one later using `xauth generate` command. X server does not use cookie's display name, thus, it does not matter with which connection family and display name cookie was created (in '-auth' file) or generated (`xauth generate`), i.e. i may just always use ':0' here. X client uses $DISPLAY value as key for searching cookie in auth file. $DISPLAY without address (e.g. ':N') refers to unix domain socket - key "hostname/unix:N" in auth file and connection will be made to '/tmp/.X11-unix/XN' socket. When connecting to local X server (DISPLAY=:N or DISPLAY=127.0.0.1:N), X client (?) will always search for cookie for unix domain socket with display N, even if i set DISPLAY=127.0.0.1:N and even if X server does not listen on unix domain socket at all (then how X client connects?). Thus, cookies for 127.0.0.1:N in auth file are never used. Generated cookies may have timeout of inactivity - if no clients using this cookie connected for specified time (both new and already established connections count), cookie is purged from X server. Cookes also may be generated as 'trusted' or 'untrusted' (SECURITY extension). So, to set up remote or local X authorization i need: 1. Set DISPLAY to point to desired address: network address or nothing (for unix domain socket) followed by display number. 2. Then either - Allow local user (for socket connections only) or remote address in `xhost` (Xsecurity(7) for "server interpreted" entries syntax). - Copy existing or generate new cookie for client and add it (with `xauth add`) with proper display name to XAUTHORITY file. Note, that X server will accept connection, if any of access methods succeed. Usually, both schemes are set up: `xhost` contains entry for user, which has started X server, and MIT cookie was created and passed to X server and stored somewhere for the user. For connecting remote client to local X server i may either use `socat` (with ssh port forwarding) or ssh X11 forwarding. With `socat` i may connect remote X client to local X server listening on either Unix Domain socket or TCP (e.g. on localhost). But when i run `socat` for redirecting connection (may be forwarded by ssh) to unix domain socket, X server will see 'socat' as sending process in socket. Thus, if 'socat' runs from user allowed in `xhost` any remote (or local) client, which connects to socat will succeed without MIT cookie at all. If socat redirects connection to TCP on localhost, MIT cookie will be required by X client for succeed (if 127.0.0.1 is not allowed by `xhost`). ssh X11 fowarding uses fake cookie. I.e. ssh listens for X11 connections on corresponding port on remote (ssh server, X client) side, passes fake (not known to X server) cookie there and stores in remote user's ~/.Xauthority file. Then, when remote X client connects with this fake cookie to ssh listening on X11 port, ssh (client?) itself checks cookie (i.e check made on local side?) and replaces with real one (known to X server). ssh listens for connections on remote side until session will not be terminated, thus (any number of) other remote X clients (e.g. started from another ssh session) can reuse this X11 connection, if they'll have correct $DISPLAY and provide correct fake cookie. So, the difference between two methods may be: 1. Many connections or only one. With ssh X11 forwarding i leave X11 port open on remote side for the duration of ssh session, but `socat` may wait only for one connection (if TCP-LISTEN does not have 'fork' option). 2. Real (known to X server) MIT cookie transfer over network. ssh never transfers real cookie over network, though method with `socat` will require this, if remote X client need it. Though, for all clients, which have access to ssh listening port on remote side, even fake cookie will be enough to connect.. 3. MIT cookie authorization. ssh definitely checks a cookie, though 'socat' redirecting to unix domain socket (with default X server configuration) does not. 4. Access to X server through unix domain socket. 'socat' can connect to local X server listening on unix domain socket (default configuration), but ssh can not. Here is example script, which demonstrates 'socat' method: https://github.com/sgf-dma/remote_x11 The first argument - is host for ssh to connect, all others are executed by ssh as command. Each script instance allows connection for only one client, but script will handle correctly several instances running (it'll increase local and remote port number). Script prefers TCP connection to X server, because user running this script will much likely be allowed in `xhost`.
DISCLAIMER. English language used here only for compatibility (ASCII only), so any suggestions about my bad grammar (and not only it) will be greatly appreciated.
среда, 27 августа 2014 г.
X11 authentication and remote X clients
- ► 2011 (12)