[59] in Kerberos
Kerberos authenticated RFS is workin
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:20:58 1987
From wesommer@ATHENA.MIT.EDU Wed Aug 20 10:10:03 1986
To: rfs-info, kerberos
Subject: Kerberos authenticated RFS is working.
Date: Wed, 20 Aug 86 10:06:31 -0500
From: wesommer@ATHENA.MIT.EDU
I set aside last night towards making RFS and Kerberos work together.
After much hacking, quite a bit of kludging, and other work-arounds, I
managed to get it working. The code is not yet ready for "release" (it
isn't all that robust, it requires the latest Kerberos release to
work properly, and I want to keep watching the log files so I know
when it breaks...).
I managed to get it working without any kernel modifications; this
made my life a lot easier. This is possible because, although the
kernel makes the actual connection, it has no idea of the
authentication used. RFS connections (which are TCP connections) are
relatively long-lived (typically as long as a login session); when the
connection is made to the server, the server does a "call-back" to a
"mount daemon" running on the client; the mount daemon provides the
authenticators. There is a noticeable "pregnant pause" of a few
seconds while the appropriate tickets are requested, and the
authenticators encoded, shipped, and decoded.
The mount daemon does the actual calls to mk_ap_req, after consulting
the /etc/utmp file to see who's logged in. This causes a bit of a
problem, as there is no documented way to specify more than one ticket
file for an application to look at; I got around this by writing my
own tkt_string routine which returned what I thought the filename
should be for each user. I haven't gotten this reconciled with
Toehold's insistance on putting the tickets in /tmp/tkt_ttyv0 rather
than /tmp/tkt<uid>.
The other major problem was translating domain names (e.g.
PRIAM.MIT.EDU) into service fullnames (rcmd.priam@ATHENA.MIT.EDU); I
wound up breaking up the domain name around the left-most period,
lowercasifying the first part, and making the second part the realm,
unless it happened to be MIT.EDU, in which case I translated it into
ATHENA.MIT.EDU.
The new server is, surprisingly enough, somewhat smaller than the old
one while executing (with perhaps 80KB of data space as opposed to
160KB in the old version); this is because it no longer builds a
permission map out of everyone's .rhosts files on startup.
- Bill
