[2072] in Kerberos
Re: Version 5.
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Aug 4 00:20:42 1992
Date: Mon, 3 Aug 92 23:58:13 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: bagate!socrates!bf4grjc (595-8439)
To: adc@tardis.cl.msu.edu (Alan D. Cabrera)
To: dinah@rockytop.tivoli.com (Dinah McNutt {sysadminzon})
Cc: kerberos@MIT.EDU
In-Reply-To: 301) 595-8439's message of Mon, 27 Jul 92 12:42:19 EDT,
Let me answer a bunch of questions, since I haven't had a chance to keep
up with the Kerberos list much lately:
From: bagate!socrates!bf4grjc (Ravi Ganesan (301) 595-8439)
Date: Mon, 27 Jul 92 12:42:19 EDT
- Can anyone provide an update on the status of The Kerberos V.5 Beta.2
that was to become available in end July.
It's late; sorry about that.... I'm working as fast as I can, to get it
out. It's a case of merging a bunch of changes in before we release it.
Date: 3 Aug 92 01:04:09 GMT
From: adc@tardis.cl.msu.edu (Alan D. Cabrera)
I'm compiling Kerberos 5.0 on a SPARCstation 2 running SunOS 4.1.1 and
I get an error when a Makefile in lib/asn.1 tries to copy a nonexistent
file, KRB5-types.h. What did I do wrong?
There's a bug in Sun's imake/cpp setup, so the Makefile that is
generated in lib/asn.1 is broken. KRB5-types.h is generated by the
ISODE program pepsy; look in the makefile just before pepsy is called.
It's should be fairly obvious where a tab character is missing....
Date: 3 Aug 92 17:10:57 GMT
From: dinah@rockytop.tivoli.com (Dinah McNutt {sysadminzon})
Organization: TIVOLI Systems
Sender: owner-comp-protocols-kerberos@shelby.Stanford.EDU
I had heard the in Version 5, tickets would no longer be stored in /tmp.
Is this true? What is the mechanism used? Does this mean you can now
have more than one user on a system and not compromise the authentication
scheme?
Well, in version 4, there was some code that could allow you to use
shared memory. In version 5, the crendentials cache (credentails cache
is the new name for the ticket file) code has been further generalized
to make it pretty easy to add a module that would store the tickets in
shared memory. However, not all systems have shared memory
capabilities, and how to use it is not always standard. Thus in our
initial release, we have not included code that would use shared memory;
it would be very easy to do so.
Note that storing files in /tmp is relatively safe, as long as you're
reasonably confident in the security of your Unix system. If you have
more than one user, it's absolutely imperative that your system be
secure; otherwise, a user who breaks the security on that system will be
able to steal tickets from anybody else logged into that machine. Even
shared memory won't help you in that case.
The place where shared memory is much more superior than storing tickets
in /tmp is when it comes to diskless workstations, whose /tmp is an NFS
filesystem on a server. On such systems, storing the tickets in /tmp
means that the tickets are being sent to the NFS server, across the
network in the clear. This is bad, since again it makes it easy for
someone to steal somebody else's tickets.
- Ted
