[OpenAFS-devel] Progress on Linux in-kernel RxRPC library
Kyle Moffett
mrmacman_g4@mac.com
Sun, 20 Mar 2005 17:05:41 -0500
On Mar 20, 2005, at 15:43, Derrick J Brashear wrote:
> As far as problems I'd like to fix in the Linux client we have,
> this is pretty low. Integrating the keyring would be done if we
> had a set of credentials to use already, really the only reason
> it's at all hard is I don't want to solve the same problem a
> Kerberos implementation will then solve probably slightly
> differently and be incompatible.
As far as OpenAFS would be concerned under the new 2.6 kernel RxRPC,
the Kerberos implementation used only matters in one program, aklog.
aklog would just need to convert/create a binary OpenAFS token from
a Kerberos ticket and create the RxRPC credential from whatever
ticket it got. 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. Once the credential is in the Linux keyring,
it would be passed to the kernel RxRPC library, which only cares
about the RxRPC ticket.
> If it's just keyrings with creds you want, the rx implementation
> can be kept in the dark and thus share code and thus enhancements
> with every other client, being portable, instead of special.
>
> Ignoring keyrings (unless you want to argue that it can be solved
> another way, in which case, speak up) what benefit does this offer?
The major advantage to integrating with the kernel RxRPC and keyring
layers is that it would eliminate the need for PAGs. The RxRPC layer
would keep track of the connections associated with each process
automatically, and would keep track of the credentials associated
with each connection. Since the current method of implementing PAGs
on Linux is deprecated and fragile, it would allow the Linux client
on 2.6 to function much better than even the old 2.4 client.
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. Ideally the system would compile in the PAG/connection/RxRPC
code when being compiled for an older kernel, and leave it out with
hooks to the in-kernel one otherwise, but I suspect that the "hooks"
necessary don't really exist in the current code.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------