X11 authentication and remote X clients

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`.