home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.windows.x
- Path: sparky!uunet!UB.com!quack!mrapple
- From: mrapple@quack.sac.ca.us (Nick Sayer)
- Subject: How do I generate valid XDM-AUTHORIZATION-1 ?
- Message-ID: <fXxsqnx@quack.sac.ca.us>
- Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
- Date: 5 Jan 1993 01:54:23 UTC
- Lines: 60
-
- Once again, X11R5, SunOS 4.1.3, ELC.
-
- Through a little trial and lots of error, I've managed to get xdm to use
- XDM-AUTHORIZATION-1 with my X terminal (an Xkernel sun3. I had to set
- up a keyFile and add a -cookie argument to the sun3's Xsun).
- Now for my ELC itself. If I attempt to create a random hex string
- (like an MIT-MAGIC-COOKIE-1) and call that an XDM-AUTHORIZATION-1,
- it fails (Xlib's 'not authorized' error). If I run xdm on the console
- frame buffer, it will generate an auth file with BOTH
- MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1. Which is fine. If I
- remove the xauth file and recreate it with just the XDM-AUTHORIZATION-1
- lines XDM generated, that's fine too. If I then save one of these auth
- cookies XDM generated, then manually start Xsun up with -auth pointing to
- a file with the previously generated (by xdm) XDM-AUTHORIZATION-1,
- that works. If I try to set up an xauth file with an XDM-AUTHORIZATION-1
- made originally for any other server, that doesn't work.
-
- So there appears to be some component of the XDM-AUTHORIZATION-1
- widget that is dependent on the display ID. This is contrary to
- the Xsecurity man page:
-
- XDM-AUTHORIZATION-1
- For sites in the US, Release 5 contains a DES-based
- access control mechanism called XDM-AUTHORIZATION-1.
- It is similar in usage to MIT-MAGIC-COOKIE-1 in that a
- key is stored in the .Xauthority file and is shared
- with the X server. However, this key consists of two
- parts - a 56 bit DES encryption key and 64 bits of ran-
- dom data used as the authenticator.
-
- When connecting to the X server, the application gen-
- erates 192 bits of data by combining the current time
- in seconds (since 00:00 1/1/1970 GMT) along with 48
- bits of "identifier". For TCP/IP connections, the
- identifier is the address plus port number; for local
- connections it is the process ID and 32 bits to form a
- unique id (in case multiple connections to the same
- server are made from a single process). This 192 bit
- packet is then encrypted using the DES key and sent to
- the X server, which is able to verify if the requestor
- is authorized to connect by decrypting with the same
- DES key and validating the authenticator and additional
- data. This system is useful in many environments where
- host-based access control is inappropriate and where
- network security cannot be ensured.
-
- It doesn't say anything special about one half of the key (56 bits really,
- but the last byte is ignored), and the other half is totally random.
-
- So, how do I generate valid XDM-AUTHORIZATION-1 keys for use in
- conjunction with xinit?
-
- By the way, is there a way around the -cookie / keyFile business to get
- xdm to use XDM-AUTHORIZATION-1 with an XDMCP display?
-
- --
- Nick Sayer <mrapple@quack.sac.ca.us> | "Do you have to keep tapping like that,
- N6QQQ @ N0ARY.#NOCAL.CA.USA.NOAM | you bloated sack of protoplasm?!"
- +1 408 249 9630, log in as 'guest' |
- PGP 2.1 public key on request | -- Captain Hoek
-