[OpenAFS-devel] Progress on Linux in-kernel RxRPC library

[Jeffrey Hutzelman]

On Monday, March 21, 2005 07:11:30 PM -0500 Kyle Moffett 
<mrmacman_g4@mac.com> wrote:


>> I'm not sure whether every security mechanism will be able to deal with
>> the server having to pass in a fixed blob at startup -- the current
>> rxkad API involves the server passing in a callback, but it generally
>> doesn't actually do much work (it looks up a key in a file, normally).
>
> The security bit in that was just some random brainstorming.  I haven't
> actually written any code for that bit yet.  If you have any better ideas,
> I'd be glad to hear them.  I'd prefer using keys via lookup in the Linux
> keyring system, although that won't work for other platforms, on Linux
> it's a cleaner API.

I really have to think about this some more.  A lookup method will work for 
rxkad, but it may mean you can't make the fileserver start accepting a new 
key version just by adding it to the KeyFile, which I think works today.

I expect a lookup method can also be made to work for rxgk.  I envision the 
context establishment being done in user mode (it's actually done via a 
series of unauthenticated RPC's to a special service).  The result of 
context establishment is that the client gets a token it can use in the Rx 
security exchange; part of that token contains data encrypted in a key 
known only to the server.  It seems like it would work quite well to give 
the kernel a copy of that key, and let it do the Rx security exchanges.

I'm just trying to wrap my head around whether using a keyring lookup is 
too restrictive.



A few other thoughts...

Rx has an additional layer of multiplexing below the UDP port, in which 
each request is for a particular service (named by an integer).  Ideally, 
it would be possible to create separate listen sockets for separate 
services on the same port.  To pick an extreme example, in a kaserver 
compiled with rxgk support, there may be as many as 7 services (the ubik 
vote and disk services, rx stats, rxgk context establishment, and three 
services provided by the kaserver), each serviced by completely separate 
code.  Similarly, a client needs to be able to control what service it is 
making a call to.  Presumably this means an extra field in the sockaddr.

How are you handling aborts?  A server signals failure of an RPC by sending 
an abort packet containing a 32-bit error code.  So, it needs to be 
possible for a server to send an abort with a specified error code.  On the 
client side, attempts to read from an aborted call should return some sort 
of error, and the client should have a way of determining what the error 
code was.

An Rx call is essentially a short-lived stream-oriented data path, and both 
clients and servers need to be able to treat a call as a stream.  So, it's 
best if in normal operation they can actually _use_ read and write, from a 
practical standpoint, rather than having to use sendmsg/recvmsg to do 
anything useful.

How are you handling call turnaround?  Clients in particular need to be 
able to signal that it is time to turn around the connection.

-- Jeff