On Wed, 2013-11-20 at 20:35 +0000, Adamson, Andy wrote: > Hi > > As suggested, I approached the Kerberos@xxxxxxx about the possibility > of a plugin architecture for libkrb5 credential cache manipulation > functions so that we could trigger the kernel GSS_context management > functions. [..] > > It appears that Solution 4: [plugin architecture to libkrb for > callouts on functions that manipulate kerberos credentials.] is a > no-go. > > I agree that Solution 1: [inotify on FILE credentials] is clunky and > won't work well. > > Solution 2: [integrate with KEYRING credentials] could work if we > insist that all NFS Kerberos credentials use the KEYRING: - e.g. the > proposed new 'big-key' type. Note there is no backporting of this > solution. Note that solution 2 is semantically identical to solution 4, you are going to try to guess what user space is doing, based on how it manipulates caches, and would have the same side effects. > I think Solution 3: [nfslog/nfslogout interfaces invoked from PAM or > other login system facility] is a good way to go. Note that a PAM > based solution where in the PAM would get us most of the way towards > providing users with a way to login and logout of NFS kerberized > shares. > > Comments on an NFS PAM that will destroy GSS context for a UID upon > logout? I prefer 3 too, let it to the login system (whether PAM based or other) to determine when it is time to destroy credentials, that's the only component that have a chance of guessing right. Of course you could also provide a user utility to force a purge. > Simo - I answered your latest comments below in-line. [..] > I think a PAM based solution will get us most of the way there. Agree. > > So the way I see it you probably want to keep the tracking in > > whatever tool you want to use to experiment (say gsskeyd) and only > > provide a downcall to the kernel that will tell it: destroy any > > cache for 'uid number (optionally pass in a session id too ?)'. > > This is what the gss-ctx keyring destroy method is - a downcall to the > kernel telling it to destroy all GSS_contexts for a UID. Why do you need to abuse the keyring interface to implement a syscall ? Or did I misunderstand what you mean by "telling the kernel to do X" ? > > This way you can replace the logic of how to keep track of what is > > going on completely in user space, where it can easily be adjusted > > and adapted as experience is gained. > > > > IE: track it completely in userspace for now and only provide a > > syscall to kill creds per UID, no tracking on the kernel side. > > Yes - I believe that is what the gss-ctx keyring code I wrote does. A keyring is not a syscall. Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
