On Tue, 2013-10-22 at 10:22 -0400, andros@xxxxxxxxxx wrote: > From: Andy Adamson <andros@xxxxxxxxxx> > > This is an RFC patchset, which will be used for testing. > > This patchset requires the "SUNRPC: destroy gss_cred and context on Kerberos credential destruction" kernel patchset. > > We need to do a lot of testing to ensure that once kdestroy and gss-ctx > gss_user_destroy is called, all existing buffered > writes using the 'destroyed gss credential + context' are serviced. > > Differences from version 1: > > - moved from nfstgt_login and nfstgt_logout to gsskeyd. > - gsskeyd automatically creates gss-ctx key on kinit and destroys the gss-ctx > key on kdestroy. > > gsskeyd will need to act differently for different krb5 credential caches. Why ? > For example, some versions of gssd store FILE credentials in FILE:/tmp/krb5cc_<UID> > while this code, written for fedora 19 uses FILE:/run/user/<UID>/krb5cc/tgt. This is incorrect, Fedora 19 use DIR type ccaches, so you should reference a cache withing the dir type, which will notmally be something like: DIR:/run/user/<uidnumber>/krb5cc for the whole collection or DIR::/run/user/<uidnumber>/krb5cc/txtXXXXXX for the sepcific cache. However note that due to issues with DIR type caches we are moving to a new KEYRING based type of cache in F20, so assuming any specific type of cache is a dead start. > As Trond suggested, if we keep gsskeyd separate from gssd, we could set up a > configuration file along the lines of the keytools' request-key.conf file to > allow both NFS and CIFS (and other filesystems) to install plugin handlers > for kinit/kdestroy events. Given in many cases (the desirable ones at least) kerberos credentials are not inited via kinit, but rather by things like pam_krb5, sssd, or directly imported via sshd, I am trying to understand how you are going to address the majority of these cases. Should users put gsskeyd in their .profile/.bashrc files or something ? > Else, we could have gssd be the process to poll inotify (given > that it already polls rpc_pipefs) and then just have it fork off the > subprocess if and when it sees an interesting event. What is an 'interesting' event ? > We need to investigate how this works when the kernel keyring is used for > Kerberos credentials. I believe that in this case gsskeyd can add the gss-ctx > key to the kerberos keyring, and it will get destroyed along with all other > keys at kdestroy. Is there any reason why you are doing this work with an utility that is separate from gssd or libkrb5 ? I think the only sensible way to handle something like this is by adding support directly in libkrb5, I do not see something external ever working reliably. I am not against it for testing purposes, but then does it need to be committed to nfs-utils ? Simo. > Andy Adamson (2): > GSSD add cc_name to upcall > ANDROS: update gsskeyd to use new /run/user/UID/krb5cc/tgt cache file > > Weston Andros Adamson (1): > WIP: Add gsskeyd > > configure.ac | 1 + > utils/Makefile.am | 2 +- > utils/gssd/gssd_proc.c | 37 ++++- > utils/gssd/krb5_util.c | 2 +- > utils/gssd/krb5_util.h | 1 + > utils/gsskeyd/gsskeyd.c | 371 ++++++++++++++++++++++++++++++++++++++++++++++++ > 6 files changed, 408 insertions(+), 6 deletions(-) > create mode 100644 utils/gsskeyd/gsskeyd.c > -- 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
