[OpenAFS-devel] afs/auth.h - ktc_token

[Marcus Watts]

jaltman@secure-endpoints.com writes:
> Marcus Watts wrote:
> > Secondly, I don't believe this *particular* structure is exported on
> > the wire.  This could probably be made 64 bits and still work.
> > There are almost certainly going to be local 64-bit rounding
> > issues, especially wherever this thing gets used with openafs &
> > kerberos times (as Jeff points out these have to remain 32-bit for
> > now).  Since this is a kerberos 4 specific structure and kerberos 4
> > itself is "going away" it's unlikely to have its 32-bit time issues
> > fixed - so there will probably never be anything that can make a
> > ktc_token that needs 64 bit timestamps.
> 
> ktc_token is communicated via pioctl.  There is no requirement
> that the pioctl client and the AFS cache manager be from the same
> release or even the same distribution.  This data structure really can't
> be changed.
> 
> Jeffrey Altman

ktc_SetToken isn't a kernel interface.  It's a library interface.

ktc_SetToken uses hand-crafted weirdness to take a ktc_token, stuff it
into a "struct ClearToken", then serializes the clear token as a byte
stream for the actual kernel interface.  There's various companion
logic involved with VIOCGETTOK, etc.  It's all horribly K4 specific.  I
believe this is true even in windows, assuming ktc_nt.c is used.  It's
possible there's some windows interface I don't know about where this
does go through straight.  I'm nearly positive this is not ever true in
unix.

The rxk5 replacement, ktc_SetTokenEx, takes a new more generic
structure "afs_token", and uses xdr to encode that inside the kernel.
It works with both rxkad & rxk5.  There are also helper functions to go
between ktc_token, krb5_creds, and afs_token.  ktc_SetTokenEx also has
backwards hacks to make it use the old K4-only pioctl interface for
older cache managers.

I'm not arguing that we should change ktc_token.  I just can't think of
any place where it would actually break anything.

				-Marcus