On Nov 20, 2013, at 4:21 PM, "Adamson, Andy" <William.Adamson@xxxxxxxxxx> wrote: > > On Nov 20, 2013, at 3:49 PM, Simo Sorce <simo@xxxxxxxxxx> > wrote: > >> 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. > > Good. > >> >>> 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 ? > > Do you think this job requires a system call? > > I felt the keyring interface gives us what we want: a way to pass some information and trigger a behavior. The gss-ctx key caches the relationship between the principals Kerberos credentials and the associated RPC layer gss_cred (which in turn has the gss_context). When a gss-ctx key exists, the principal associated with the UID has kerberos credentials (located in the Kerberos ccache this is confusing: the _location_ of the KRB5 ccache is stored in the gss-ctxkey, not the actual creds... > stored in the key) that are used for NFS, and the key serial is stored in the gss_cred. > > From kernel documentation: Documentation/security/keys.txt > > "This service allows cryptographic keys, authentication tokens, cross-domain > user mappings, and similar to be cached in the kernel for the use of > filesystems and other kernel services." > > I think the gss-ctx key fits into the above description (under "similar"), so I don't think of this use as an abuse. > >> 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. > > Yes, but it does as you suggested "provide a downcall to the kernel that will tell it: destroy any > cache for 'uid number" > > What is the disadvantage of using the keyring? > > --Andy > >> >> 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
