On Sat, Feb 5, 2011 at 7:03 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Fri, 21 Jan 2011 15:34:27 +0000 > David Howells <dhowells@xxxxxxxxxx> wrote: > >> >> I'd like to propose a discussion topic for the LSF: how best to implement a >> common key type for use by NFS, CIFS and AFS such that, say, a kerberos key >> can be encapsulated within one and then be pulled out by various filesystems. >> >> Furthermore, it would be necessary to allow the request_key() upcall mechanism >> to perform GSSAPI queries. >> > > I would be interested in discussing this as well. Currently CIFS > "punts" to some degree and offloads almost all of the SPNEGO blob > construction to userspace. So, for CIFS this would involve moving more > of this code into the kernel. I think that's a good thing since it will > make it easier to do mutual-authentication, etc... Yes. I also agree, in part because the more the upcall has to go to userspace the more likely a reconnect (network connection drop) can cause problems when memory available to userspace is constrained by a large amount of cached data on the network mount. > This would make it more plausible to store krb5 credcaches in the > kernel keyring too. Modern MIT krb5 libs can do this today (I think), yes > The difficulty here is that request_key() is "stateless", so we need to > think about how to manage GSSAPI contexts across multiple upcalls...or > plan to implement large swaths of the GSSAPI in-kernel. > It might also be helpful to couple this with some consolidation and > cleanup of the ASN.1 parsing code in the kernel. There are at least 3 > separate implementations in the kernel today (one in cifs, one in > sunrpc, and one in iptables). This is harder, but would also simplify future work as well (such as SMB2, which will require this more often in sessionsetup than cifs) -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
