xlogin-xdmcpserver(8)

NAME

xlogin-xdmcpserver - Listen for xdmcp UDP data and answer, spawns xlogin processes to satisfy requests

SYNOPSYS

xlogin-xdmcpserver [-h|-help] [-p|-port <port>] [-a|-addr <address>] <OTHER ARGUMENTS>

DESCRIPTION

xlogin-xdmcpserver is a server program for the X windows X Display Manager Control Protocol.

OPTIONS

-h or --help
    display a short help text

-p or --port <port>
    specify the port to listen to (default is 177)

-a or --addr <address>
    specify the IP address to listen to (default is 0.0.0.0, or all addresses on all interfaces)

<other arguments>
    The rest of the options will be passed as is to xlogin when it is spawned.

SECURITY

Poor ! Lets be honest here XDMCP is a pretty weak protocol from a security perspective. Its biggest downfall is that the cookie, a kind of "poor mans secret key" is handed to the X server generating the query via the X socket. This can be sniffed by another network user, the time window is pretty small but its possible.

If security is very high on your list then you should not be running distributed X windows without extra encryption.

Even with the secuirty issues for some home, small office and school users its still a useful way of doing things. A secret is still a secret as long as nobody was listening when you shouted it across the room.

EXAMPLES

xlogin-xdmcpserver -date -pos 10,10 -background tree.jpg

(starts xlogin with args -date -pos 10,10 -background tree.jpg)

or

xlogin-xdmcpserver -a 127.0.0.1

(makes xlogin-xdmcp server listens only on localhost).

At the moment the server only supports X servers asking for a session with the -query option, chooser modes are not currently implemented.

To get a session from a remote machine try something like:

X -query <servername> :Local display number

A real world example would be :

X -query 192.168.1.116 :1

Note the space between the IP and the display number, it matters !

The xlogin-xdmcpserver should send the requesting X server a cookie then launch an xlogin process to satisfy the query.

If you use Xvnc instead, you must use the -once parameter, otherwise after the first session ends Xvnc will not ask for the next session from xlogin-xdmcpserver. Specifying -once makes Xvnc exits after the session ends, so you will need some sort of process manager to restart it if you want to have it running continously.

BUGS

Its possible to specify -identity on the command line for automatic logins for any requesting X server. This is a bad idea as almost everything stores some transient state in the users home directory. Even firefox without a window manager is not safe in this mode. Don't do it, its not big or clever and having multiple sessions with the same home directory will piss off KDE/GNOME something rotten.

Currently this implementation does not hold much in the way of state, it simply replies to all queries with a positive response. Its like an old relative at a family gathering that replies with "yes dear" to all questions but doesn't in fact listen the conversation at all.

On paper a race condition exists where an X server sending a second query could bump into the xlogin-xdmcpserver just after its started to spawn an xlogin process. The result would be two xlogin processes, with access controls on the second cookie exchange would fail, but users running with -ac as well could get two login boxes. I've never seen this in the real world but it is possible.

AUTHOR
Jonathan Andrews (jon (at) jonshouse.co.uk)

SEE ALSO
xlogin(8) xlogin-makeidentity(8) xlogin-rootjpeg(8)