[OpenAFS-devel] rxgk updates/call for help

[Benjamin Kaduk]

The big news: I have enough functionality in place for my test cell to use
rxgk for file data.  But, there's still some hacks in place of missing
functionality.

The vldb has no way of indicating whether a given fileserver supports
rxgk.  This is a big dealbreaker -- my hack for now is to allow rxgk
tokens for a fileserver if it's colocated with a database server, since
the database servers must all have the shared cell-wide key in order for
things to be functional.  We must have vldb support to get to the current
level of functionality for fileservers that are not colocated with
database servers.

If you have some familiarity with the vldb format, please, please, try to
write it up, and think about how it could be extended to support rxgk
fileservers.  A flag to indicate rxgk support using the shared cell-wide
key is probably the bare minimum, but we really want the ability to store
the per-fileserver key in the database, to support departmental
fileservers that do not have the shared cell-wide key.  Along side such
keys, we should also have a provision for storing the GSSAPI name(s?)
which is permitted to update that key.

I have most of a bare-bones implementation of pts extended names, but only
with the fallback to an implicit mapping of krb5 GSS names; there's no
support for storing actual extended names (which requires a database
format revision).  Just this fallback is enough to provide equivalent
functionality to what is currently available with rxkad, so adding full
functionality is not an urgent priority.

Updates on the smaller in-progress items inline.

On Thu, 5 Jun 2014, Benjamin Kaduk wrote:

> On Tue, 1 Apr 2014, Benjamin J Kaduk wrote:
>
> > I should update on what I'm working on.  I picked up the item to move rx
> > epoch/cid generation into the core rx code, which is sitting in gerrit as
> > 10840-10843.  Looking through my gerrit changes, it would be nice to get
> > 10526 in as well, to help indicate which places in the tree have code that
> > conditionalizes on the rx security class.
>
> 10840-10843 are still sitting in gerrit.  They would probably need to be
> rebased before being mergable, at this point, though.
> I need to fix a few issues that were noted in 10526.

10526 is merged, but 10840-10843 are still sitting in gerrit awaiting
review.  This is a generic improvement that would be worth doing even if
rxgk did not depend on it.

> Looking at http://wiki.openafs.org/RXGKToDo/ , there are still several other
> open tasks:
>
[...]
>
> getting rxgk tokens into the kernel.  I looked at this some; the existing
> pioctl SetTokens2 has enough rope to handle rxgk tokens, and the in-kernel
> tokenJar structure will differentiate by type.  Only rxgk tokens for dbservers
> should be sent into the kernel this way, and the cache manager will call
> AFSCombineTokens as needed.  Once we can have rxgk tokens in the tokenJar,
> then we can look at using them for outgoing connections.

As part of my test cell functionality, I did make a gklog utility to get
an rxgk token and shove it into the kernel.



There is a symbol conflict with the PrAuthName data structures that are
embedded in the rxgk RPC-L, and the full PrAuthName structures to be
implemented for the ptserver interfaces.  Due to the order in which I
implemented things, the rxgk ones have the "real" names, and the ptserver
ones have "dummy" names (with a capitalization change, so PRAuthName).
This seems backwards, and at some point the rxgk types should be changed
to something else so the ptserver can use the standardized names.  That's
a little bit of a grunt-work patch, but would be useful if someone is
interested.


At the moment, I have disabled rxgk bits for UKERNEL, as rxgk depends on
the rfc3961 functionality, which is not currently built into libuafs.  I
made a start at pulling it in, but reverted it.  There's some excitement
with what header files are needed and where they come from that I didn't
spend enough time to untangle.  This should get fixed at some point; it is
not particularly urgent to me, as I am not really a consumer of libuafs.


-Ben