[OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Jeffrey Hutzelman]

On Sunday, February 18, 2007 01:23:42 AM -0500 Marcus Watts <mdw@umich.edu> 
wrote:

>> Date: Fri, 16 Feb 2007 12:50:38 -0500
>> From: Jeffrey Hutzelman <jhutz@cmu.edu>
>> To: Marcus Watts <mdw@umich.edu>, openafs-devel@openafs.org
>> cc: Jeffrey Hutzelman <jhutz@cmu.edu>
>> Subject: Re: [OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT
>>
>>
>>
>> On Friday, February 16, 2007 06:32:45 AM -0500 Marcus Watts
>> <mdw@umich.edu>  wrote:
>>
>>
>> > The intention is that the "generic" token interface be capable
>> > of being augmented with with future token types (such as rxgk) in
>> > the future.  The assumption is that in a given realm,
>> > all db & file servers be capable of dealing with the same
>> > credential type, and that is the responsibility of aklog/klog,
>> > with input from the user & from the kdc, to get the appropriate
>> > credential.  The "capability" call is intended to return
>> > information on cm capabilities.  For now it only supports
>> > rxk5 encryption types.  In the future, it might also return
>> > information on other things, or have a companion pioctl
>> > to allow setting things.  This might be used to get/set
>> > locking behavior or fs setcrypt.
>>
>> We bashed out a lot of the details of what the new interfaces will look
>> like and what the fallback and transition mechanisms need to be at the
>> rxgk  hackathon last month.  Details, including the specifications for
>> the new  VIOCGETTOK2 and VIOCSETTOK2 pioctls, can be found at
>>
>> <http://www.afsig.se/afsig/space/rxgk-client-integration>
>>
>> -- Jeff
>>
>
> Interesting.  rxk5 already has a VIOC_GETTOKNEW VIOC_SETTOKNEW using
> _CVICEIOCTL(7) and (8).  Is this a proposal to build on top of that
> interface?


This is the interface we propose to actually implement in the cache 
manager, instead of the one that was in your patches.  The interface you 
had was not rich enough to handle multiple tokens per cell, which is 
necessary for the transition and fallback behavior we defined.  The 
impression I got from Jeff and Derrick was that you didn't have rxk5 
deployed anywhere where this change would be a problem,

Incidentally, your patch also uses three 'C' pioctl numbers (6,7,8) without 
them actually having been assigned to you; the recent patch from Matt 
Benjamin makes the same mistake.  Numbers in this space must be obtained by 
sending a request to registrar@grand.central.org; otherwise, you risk 
causing a collision, as the GetCapabilities pioctl included in the rxgk 
patch does -- _CVICEIOCTL(6) is already assigned for VIOC_CREATE_MT_PT.

-- Jeff