[OpenAFS-devel] struct rx_identity and compound identities

[Benjamin Kaduk]

On Wed, 4 Dec 2013, Simon Wilkinson wrote:

>
> On 4 Dec 2013, at 03:18, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
>> Back in 2010, Siomn added an rx_identity structure to store identity information, a structure that is similar to, but not exactly compatible with the PrAuthName type for which RPC-L is given in draft-brashear-afs3-pts-extended-names
>
> The idea of rx_identity was to provide an analogue for PrAuthName, 
> without requiring consumers to pull in the whole mess of an XDR 
> generated header (a particular issue if you happen to be within RX 
> itself!). It also resolves the dependency ordering, and layer violation, 
> of having an RX security class depend on a ptint structure. We also do 
> some helpful things, like providing the displayName as a NUL terminated 
> string that can just be printed.

Well, rxgk has an XDR generated header involved for its own routines, and 
actually it seems likely that we'll need to duplicate the PrAuthName RPC-L 
for rxgk becaues of the layering issue.  I believe that if the type was 
declared as an ordinary C type in rx, as long as the declaration was 
exactly compatible with the rxgen output, things would still work okay.

I wanted to use asprintf("%.*s") to convert the PrAuthName length-value 
type to a printable string, but alas we have no such function in the 
kernel.  It's not hard to do other ways, though.

> In that vein, if you have an array of PrAuthNames, you would have an 
> array of struct rx_identity pointers

Okay, I can extend my prototyping in that way.  The logic for super-user 
checks and everything else will remain hand-wavey until we have answers 
for the issues that Jeff raised, of course.

I do believe that I have (hacky, requires MIT krb5/gssapi) rxgk-bos 
running okay; I'll probably be deploying it on a test cell the near future 
(after a security audit pass).  Already some additions/modifications that 
will be needed for existing APIs are becoming clear; at least some of 
those patches could go into master even before the rxgk document goes 
final.  (Simon, more input from you on that document would be quite 
appreciated!)  I might try my hand at using rxgk for the ubik 
synchronization connections before cleaning up the rxgk codebase I have 
and letting people pore over it in gerrit -- the bosserver changes were 
tiny and there's a library routine to print tokens....

-Ben