[2177] in Kerberos
xdm and Kerberos
daemon@ATHENA.MIT.EDU (Peter Lister, Cranfield Computer C)
Wed Sep 9 12:15:08 1992
To: kerberos@Athena.MIT.EDU, info-afs-kerberos@transarc.com
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, cckrc@xdm001.ccc.cranfield.ac.uk
Date: Wed, 09 Sep 92 15:51:22 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
We are looking at alternatives to DEC's rather brain-dead login X login
window and session manager (it works via has extensions to /bin/login
that start and X server and a login and password prompter). We are
using DECathena, I should add, so /bin/login obtains a (v4) Kerberos
ticket and runs attach.
xdm looks like a good bet, combined with our a simple home-brewed
session manager, but it seems to perform authentication directly via
compiled in function calls. The Kerberised versions (MIT and AFS) use
different functions, but they're still compiled in.
Given that we have a working login, it appears that the obvious step is
to pipe the I/O of the login window to and from the existing
/bin/login. Using the same /bin/login X and and non-X logins has advantages.
Has anyone done this? Is there any convincing reason not to do so? As
it stands, DEC's login system does this - using what is enigmatically
referred to as "an extended protocol". Given that it's evidently
possible to for login to decode the key, this protocol can't be full
authentication, and hence not terribly effective. The only objection I
can think of is that an snooper could maybe intercept the password more
easily as it crosses the pipe, though this doesn't strike me as being likely.
Peter Lister p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology, Voice: +44 234 750111 ext 3157
Cranfield, Bedfordshire MK43 0AL England Fax: +44 234 750875
