Plugins for libkrb5 credential cache management functions

[Adamson, Andy]

Hi

I'm working on solving the "NFS access to Kerberized mount after Kerberos credentials are destroyed" problem, and would like the Kerberos communities comments.

Problem:
------------
There is currently no mechanism to destroy the Kernel GSS context when the associated Kerberos credential is destroyed. When a user logs out, or runs kdestroy, the GSS context still allows access to Kerberized NFS shares until the GSS context lifetime expires. Yecch.

There is also no method to communicate to the kernel when a Kerberos credential, that has an associated GSS context, TGT has been refreshed. The kernel finds out by trying to refresh an expired GSS context.

Overview;
-------------
Kerberized NFS creates a GSS context between each user principal and server principal, and more often than not, between each client principal and server principal.

For the Linux NFS client, the GSS context is stored in the kernel keyed by the <UID, server, service> tuple. The GSS context lifetime equals the remaining lifetime of the TGS established between the initiator principal and server principal at the time of GSS context creation.

GSS contexts are created by rpc.gssd, a user land daemon that uses the Linux kernel pipefs for communication with the kernel.

When an NFS request finds an expired or nonexistent GSS context, an upcall is made to rpc.gssd requesting a new GSS context. The rpc.gssd daemon, through the GSS library, initiates a request for a new TGS which, of course, is limited to the lifetime of the associated TGT.

Solution Overview:
-------------------------
There are two aspects to a solution to this issue.

1) How to handle buffered writes that require the GSS context to complete after the principal'sincipal's Kerberos credentials are destroyed. E.G. After kdestroy the GSS context can only be used by pre-existing buffered writes and then the GSS context is destroyed and gss_destroy_context message is sent to the server.   

2) What mechanism is used to trigger the kernel code in #1 in response to Kerberos credential destruction.

Potential Solutions:
---------------------------
I have coded a solution to #1 and submitted a RFC patch set.

I have coded a #2 prototype to test the kernel code to solve #1. This prototype registers a new keyring type (gss-ctx) when the auth_rpcgss kernel module is loaded. A gss-ctx keyring is added to the user's session keyring (KEY_SPEC_USER_SESSION_KEYRING) upon successful GSS context creation, and destroyed when the principals Kerberos credential cache is destroyed. The gss-ctx key destruction method calls  the #1 solution. The prototype uses a daemon, gsskeyd, to add the gss-ctx key  and then sets up an inotify watch on the FILE: based Kerberos credentials, destroying the gss-ctx key when the FILE: based credential is destroyed. I am able to test the kernel portion (#1 above) using this prototype.

The question of how to architect #2 remains.

Solution 1:  Inotify watch of FILE: based credentials. The prototype inotify watch of the Kerberos FILE: based credentials is clunky, based on the FILE: credential type, and the NFS community (rightly so) does not approve of this architecture.

Solution 2: Another solution is to insist the NFS use the KEYRING: based Kerberos credentials. With the advent of the new proposed 'big_key' key type (see Red Hat [Bug 991110] RFE: Add new kernel key type and per-UID persistent keyring for Kerberos support) this becomes a viable solution. Here we could either add the gss-ctx key to the KEYRING: keyring so that the gss-ctx key is destroyed when the keyring is destroyed, or hook into the kernel KEYRING: destructor some how.

Solution 3: Another solution would be to create an "nfslog" and "nfslogout" similar to AFS klog and unlog, and then create a PAM module. This solution could also use the gss-ctx keyring.

Solution 4: AFAICS the most versatile solution is to add a plugin architecture to libkrb for call
outs on functions that manipulate kerberos credentials.

Comments appreciated.

-->Andy