[OpenAFS-devel] New SetToken and GetToken pioctls

[Simon Wilkinson]

On 16 Feb 2010, at 19:56, Marcus Watts wrote:

> Simon Wilkinson <sxw@inf.ed.ac.uk> writes:
>> With the rise of new security mechanisms, the old Get and Set Token =
>> pioctls are no longer capable of handling all of the various key =
>> material that we need to shift between userspace and the kernel. A =
>> proposal to remedy this was originally on the (now defunct) AFSIG  
>> wiki, =
>> and some of what is below is built from the discussions there.  
>> Since =
> ...
>> Any comments?
> ...
>
> Have you cleared your name changes with the Arla folks?   
> pioctl_set_token
> specifically comes from Love (should you give him credit?)

Name changes don't affect the wire protocol. I've been careful to  
leave types, and field positions intact. Where I have changed names,  
it's been in the interests of clarity, and avoiding conflicts with  
other existing structures.

I've actually received feedback suggesting that the current  
ktc_setTokenData should be renamed (because it's used for both Get and  
Set), so I'll probably end up calling that ktc_tokenData.

> Gratuituous name changes don't simplify rxk5 integration.

I doubt rxk5 will have anything to do with the names used in the XDR -  
it won't be the sole consumer of the new Set and Get pioctls, after  
all. The current implementation adds the concept of a 'tokenJar' to  
the kernel module - each PAG has one of these. The new pioctl  
operations manipulate these jars, and interface functions are provided  
to allow security classes to pull usable tokens out of the jar. This  
abstracts out the storage requirements of particular classes from the  
unixuser structure, and should help the code from becoming overrun  
with #ifdefs.

I'm hoping that the work I'm doing on cleaning up the security class  
interfaces throughout the AFS code should actually make it easier for  
both rxgk, and rxk5 to drop in. There have been a lot of changes  
recently (look for commits from sxw@your-file-system.com) aimed at  
carving out the necessary hooks - the way clients and servers allocate  
security layers has been changed, aklog has been radically  
restructured to permit easier addition of other token types, the afs  
pioctl code has been reworked, a new kernel token cache implementation  
has been produced, and so on. I suspect these won't simplify the task  
of porting rxk5 forwards, but they will hopefully mean the amount of  
code you have to merge is significantly less.

> For rxk5, it was specifically intended that the kernel understand
> all tokens given to it.

The intention of the token jar is that it will store tokens for all.

> The ability to set tokens the kernel does
> not understand opens the "kernel credentials cache" discussion (which
> you might not want), not to mention the difficulty of fixing problems
> in that which does not complain.

Many of our tools currently rely on retrieving tokens from the kernel  
in order to perform operations. This is the path of least surprise for  
our users, and is one I'm keen to continue to support. We have to  
permit version skew, where it's possible that userspace support one  
set of RX security classes, and the kernel support a different set.  
So, userspace needs to be able to set, and retrieve, tokens that the  
kernel doesn't understand. We also need to be able to support the  
kernel and userspace security layers having different feature sets.  
For this reason, multiple tokens for a single security mechanism may  
be added, some of which will be usable by the kernel, and others  
usable by userspace.

>  In rxk5, there is also a separate
> mechanism whereby aklog & friends can determine what token types will
> be acceptable to the kernel.

Sure - userspace needs to have a way of negotiating tokens which are  
going to be usable by the kernel. But it also needs a way of storing  
tokens for its own use.

> jhutz mentioned the evils of AFSTOKEN_EX_SETPAG, and I quite agree  
> that
> it's most evil.

All of the feedback I've received so far has advocated dropping this  
from the new pioctl. However, I'm very aware that this is developers  
talking. I'd be interested in feedback from users too, and I'll  
shortly send an email to the info list about this one topic.

Cheers,

Simon