>>Eeeeeuuuwww :-) That would certainly work, but it would be a hellish
>>hack. If you _did_ use that scheme, however, there is one drawback that
>>I can see. Even if you call ktc_ForgetAllTokens(), the structure that
>>holds your token stays around for a while afterwards (2 hours). If you
>>have a lot of people in your cell retrieving their mail via this method,
>>the structures tend to take up a lot of kernel memory over time and
>>cause really slow lookups (the hash table inside the kernel isn't that
>>big). I don't have any numbers on this, but I have seen other people
>>report problems with similar things in the past.
>
>How is that different from lots of people connecting to a POP server that
>just authenticates via a password and userid to afs?
Presumably the POP server wouldn't need to actually install the token into
the kernel, if it wasn't reading or writing any files to AFS. But if it
was installing the token into the kernel, then it wouldn't be any different
at all. I don't know what the various POP server implementations do,
however.
>Just made some changes to my token passing code, and unfortunately, you can
>put ANY information in that field... I was kindof hoping it wouldn't let
>you SetToken if the information didn't match...
The problem is that the information that is used as the proof of identity
is encrypted with a key that you don't know, so there is really no way
to match up anything.
>It just seems a little strange that there isn't any way to ask the
>authentication server "who am I authenticated as".
I think it would be easy to write a little server that ran along side
of the kaserver that you could send a ticket to and it would decrypt it
and send you back the user inside of it.
>As far as 'rsh' across cells and such, why bother... Just install 'ssh'...
>it works a whole lot better, and builds almost everywhere... (i'm currently
>using between: aix 3.2.5, hpux 9+10, solaris 2.5, linux 1.2.13, and sgi
>irix 5.3). Not to mention it's other benefits (rsa authentication of hosts,
>encryption of streams, compression, etc.) and the fact that you can do
>rlogin in addition to rsh, and rcp.
I thought you didn't want to modify all of your client machines? :-) I
have looked at ssh before and it solves some problems quite nicely, but
I think that if you're using Kerberos, you might as well go whole-hog and
Kerberize everything; then you get Kerberos rsh for free.
--Ken
