[1363] in NetBSD-Development
Re: token problems with NetBSD-AFS
daemon@ATHENA.MIT.EDU (William O Ferry)
Sat Aug 3 01:21:34 1996
To: Greg Hudson <ghudson@MIT.EDU>
Cc: netbsd-afs@MIT.EDU
In-Reply-To: Your message of "Sat, 03 Aug 1996 00:07:30 EDT."
<199608030407.AAA05686@glacier.MIT.EDU>
Date: Sat, 03 Aug 1996 01:20:33 -0400
From: William O Ferry <woferry@WarpDrive.COM>
In message <199608030407.AAA05686@glacier.MIT.EDU>, Greg Hudson writes:
>> Anyhow, when ktc_SetToken() is called, a *4GB* file is created, such
>> as /tkt/p3. ka_GetAFSTicket() then starts writing to this file,
>> which needless to say fills the HD before completing
>
>This is almost certainly a bug in our AFS libraries.
>
>What's probably happening here is an lseek() or ftruncate() call with
>an offset argument being passed as a 32-bit number (and no prototype
>to correct it). NetBSD uses 64-bit file offsets, so this could show
>up as a huge offset in some cases.
>
>A prime candidate seems to be the duplicated Kerberos library code in
>auth/ktc.c. I've added a few off_t casts to that code, and am doing a
>built now. I can stash the resulting libafs somewhere and tell you
>where to pick it up.
Greg,
The new library almost worked like a charm. One problem I had
was an undefined symbol, lcstring and ucstring, which required me to
include the old libauth as well as the new one. But it created a 210
byte ticket file and wrote a valid ticket to it! Only remaining
problem is the fact that it made the ticket root.wheel, mod 600, so
login (or kinit, etc) couldn't read it... =) It looks like the AFS
library chose the filename /tkt/p4? Is there somewhere that I can
find out what name it picked (I guess it sets the KRBTKFILE env
variable, eh?), so that I can chown it. I also have to figure out
why it's not deleting it at the end, but these are problems with my
program, not AFS, I'm sure.
Thank you VERY much!!!
Will Ferry
