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

[Derrick J Brashear]

On Sun, 20 Mar 2005, Kyle Moffett wrote:

> Below what you quoted I said this:

(I redacted the parts I felt were out of scope, and I will comment on why 
below. I guess I should have just commented why the first time and we 
could have skipped one back and forth)

>> Since it just uses Kerberos library calls to get the
>> Kerberos tickets, it doesn't care whether the tickets are in the
>> current file-type database, an in-memory database, or the Linux
>> kernel's keyring system.

But...

> To say it simply, aklog doesn't care about your Kerberos ccache, because
> that's _only_ an issue for the MIT or Heimdal Kerberos libraries.  Once
> you get a ticket from the _library_ interface, you can do whatever you
> want with it.

Yes. But I'm not worried about the aklog part here (and really, my hope is 
we can get to the point where userland helpers can autoget afs tickets for 
you). I'm worried about the kernel. The kernel isn't going to pull in 
complete kerberos libraries, so the format of the cache matters. aklog is 
easy, aklog exists in userland and can do whatever, but it's not what's 
providing the credentials to Rx when Rx needs them, it's just a tool used 
to prime that cache.

>>> The major advantage to integrating with the kernel RxRPC and keyring
>>> layers is that it would eliminate the need for PAGs.  The RxRPC layer
>> 
>> Except you're ignoring the part where I asserted you don't need RxRPC
>> to use keyrings and hence can get rid of the PAGs without it. So either
>> tell me I'm wrong and why, or answer the question I asked.
>
> Under the current OpenAFS code you still need to keep track of the
> per-process connection data, which doesn't really belong in a key.  With
> the Linux RxRPC layer, that keeps track of it for you. Again, I said this
> already, but you snipped it.

Ok, this is a semantic argument, namely, how you want (or expect) it to 
work, though. It's something to discuss, but:

>> The RxRPC layer would keep track of the connections associated with each
>> process automatically,

What does this mean, though? If I get tokens once, why should running ls 
and running pine result in different connections to the same fileserver to 
use the same tokens to fetch the binaries themselves and/or to bulkstat?

Or, I guess the simple summary is, I don't think I actually care at a 
process level. Or, I don't think I need to. I think I care at what for 
keyrings is a session level, and keyrings solve this problem for me as the 
sessions are in it's own scope.

>>> The biggest problem that is likely to arise with OpenAFS is that the
>>> code-base basically lacks the abstraction to make this easy to patch
>>> in.
>> Not really. It's trivial to ignore the groups-encoded-PAGs mechanism.
>
> I've not seen this done.  AFAIK, the current OpenAFS code still looks in
> 2.6 to find a sys_call_table to patch (Even though it doesn't have the
> nice symbol to find anymore.  (Please correct me if this has changed).

That's correct, you haven't seen my (incomplete) code. If you want, you 
can. The part that ignores the group encoding was the first part done. 
This implementation assumes we don't want to solve the creds-in-kernel 
problem ourselves, and instead puts a pag number (an index, basically) 
directly into the key. All the index number is used for is a lookup to get 
creds out of a table. Well, nothing precludes you from making the lookup 
pull the keys out of the keyring instead of looking at some index for 
creds you stuffed into the kernel directly. But since I wasn't messing 
with cred storage for now, I didn't write it.

> I am not saying that ignoring the RxRPC layer is at all bad, I just want to
> make sure that you know about the other options currently in development in
> Linux.

(I do, there's certainly no reason not to make sure everyone else does)

> The benefits of using the kernel RxRPC layer is that it is far more
> integrated into the Linux kernel than the AFS RxRPC layer is and provides a
> more Linux-like interface.  However, I do understand that may not work well
> for OpenAFS.

It might. But you know my concerns now. Actually, it may get to the point 
where RxRPC is easy enough for OpenAFS to use that we do it. It's just not 
(at least in my opinion, which you might think has more weight than it 
actually does) a foregone conclusion thaat it's the right answer.