Path: utzoo!utgpu!watserv1!watmath!att!att!emory!wuarchive!julius.cs.uiuc.edu!apple!bbn.com!mit-eddie!bloom-beacon!EXPO.LCS.MIT.EDU!keith
From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: locking out users from a server....
Message-ID: <9010312001.AA20409@xenon.lcs.mit.edu>
Date: 31 Oct 90 20:01:14 GMT
References: <1990Oct31.000115.26078@Think.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 24


> Does this mean that MIT-MAGIC-COOKIE-1 authorization can only be used when
> the server is running on the same host as xdm?  What is done for X
> terminals and other random X servers?

When the X terminal is controlled by XDMCP (as most should be), xdm is willing
to generate authorization keys for use by the session.  The recent Tektronix
terminals support MIT-MAGIC-COOKIE-1 authorization, which surprised me quite a
bit.  I just plugged it in and it worked.  Other terminal vendors will be
providing this as well, sooner if you clamour loudly for it.

If you're still running xinit, you can set up an authorization file and type in
your own cookie and tell the X server to use that file for authorization
information, using the -auth option to the server (which is how xdm transmits
the cookie to local servers now).

From the look of things today export-law wise, we'll be able to also provide
XDM-AUTHENTICATION-1/XDM-AUTHORIZATION-1 as well, giving you a system which
doesn't depend on the security of the underlying transport for secure
authorization.

I think we'll also see kerberos (or other network authentication systems)
schemes which will help resolve the issues of per-user access control and key
dissemination.