On Wed, 4 Dec 2013, Simon Wilkinson wrote:
On 4 Dec 2013, at 03:18, Benjamin Kaduk <[email protected]> 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
