thj@dde.dk (Thomas Herlin Jensen) (04/25/91)
Hello everybody,
I have some problems regarding authorisation and XDM.
I use our own developped Supermax multiprocessor as a host and
a NCD17c X-terminal, with X11R4 Server (version 2.3K).
The XDM is taken from the X11R4 patchlevel 8 (original MIT distribution).
The problem:
We get a timeout at the first XOpenDisplay the XDM tries to connect.
If something is wrong with the authorization you would presume that the server
simply rejects the connection, but our XDM just times out.
Xhosts is ofcourse set to my local host
More details:
Tracing the problem I have come to the point that the following scenario
takes place.
Display manager xdm Display NCD
<----------- Query
Willing ----------->
<----------- Request
Accept ----------->
- mitAuth generate
for proto display
<----------- Manage
- save auth data in
generated Auth file
1) -****
XOpenDisplay -----------> timeout
???????
2) -Set AUTHORITY
3) -Load resources with
xrdb
At this point I have looked at the MIT server sample implementation.
When an XOpenDisplay request arrives the first thing checked is the
authentification, by looking into the auth file. For the sampleserver this is
quite straight forward, as it is assumed to be local and started from the
XDM at point 1), e.g. Xsun -auth /usr/lib/X11/xdm/AuthXXXX .
But how does this comply to a remote X-Server ???????????
The first thing you think of is the missing XAUTHORITY environmental variable,
that is needed, but according to the code the XAUTHORITY is set at point 2)
after the XOpenDisplay.
Also the resources for xdm are loaded later, at point 3).
Does anybody have a guess what could be wrong ?
Any hints are highly appreciated ?
------------------------------------------------------------------------------
Thomas Herlin Jensen Tel: int +45 42 84 50 11 (UTC + 1)
Dansk Data Elektronik A/S Fax: int +45 42 84 52 20
Herlev Hovedgade 199 Telex: 35258 dde dk
DK-2730 Herlev, Denmark E-mail: thj@dde.dk
--
Thomas Herlin Jensen Tel: int +45 42 84 50 11 (UTC + 1)
Dansk Data Elektronik A/S Fax: int +45 42 84 52 20
Herlev Hovedgade 199 Telex: 35258 dde dk
DK-2730 Herlev, Denmark E-mail: thj@dde.dkschoch@trident.arc.nasa.gov (Steve Schoch) (05/02/91)
In article <1991Apr25.130901.6290@dde.dk>, thj@dde.dk (Thomas Herlin Jensen) writes: |> Display manager xdm Display NCD |> <----------- Query |> Willing -----------> |> <----------- Request |> Accept -----------> |> - mitAuth generate |> for proto display |> <----------- Manage |> - save auth data in |> generated Auth file |> 1) -**** |> XOpenDisplay -----------> timeout |> ??????? |> |> 2) -Set AUTHORITY |> 3) -Load resources with |> xrdb |> |> At this point I have looked at the MIT server sample implementation. |> When an XOpenDisplay request arrives the first thing checked is the |> authentification, by looking into the auth file. For the sampleserver this is |> quite straight forward, as it is assumed to be local and started from the |> XDM at point 1), e.g. Xsun -auth /usr/lib/X11/xdm/AuthXXXX . |> But how does this comply to a remote X-Server ??????????? For a remote server using XDMCP, the authorization cookie is sent to the server as part of the Accept message. Xdm then gives that same cookie in the XOpenDisplay call. There are actually two "auth" things sent around that are easy to get confused: authorization and authentication. I'm not sure to which you referring in your question above. Authorization is the key that is passed to a local server with the "-auth" argument and is sent by each client in the XOpenDisplay call. If the authorization scheme is MIT-MAGIC-COOKIE-1 (the only one I've ever used) the server simply does a binary comparison of the key sent with the key give to it with the "-auth" argument (local server) or the "Accept" packet (XDMCP server). Authentication is the key sent by the server in the "Request" packet along with the manufacture display ID. The only authentication in xdm currently is XDM-AUTHENTICATION-1 which uses DES to decrypt something sent by the server and then compares it with the value in some file. If they match then xdm sends an "Accept" packet. If they don't it sends a "Decline" packet. I don't think this is used very much. Steve