On Jul 22, 2013, at 2:50 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Fri, 2013-07-19 at 17:06 -0400, andros@xxxxxxxxxx wrote: >> From: Andy Adamson <andros@xxxxxxxxxx> >> >> pNFS data servers are not mounted in the normal sense as there is no associated >> nfs_server structure. >> Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible" >> uses the nfs_client cl_rpcclient for all state management operations, and >> will use krb5i or auth_sys with no regard to the mount command authflavor >> choice. For normal mounted servers, the nfs_server client authflavor is used >> for all non-state management operations >> >> Data servers also need to use the same authflavor as the MDS mount for >> non-state management operations. Add a strut rpc_clnt to struct nfs_client for >> data server connections. > > Is that sufficient? As far as I can tell, there is nothing that states > that the data servers must use the same security mechanism for all the > files? > In fact, section 13.12 specifically mentions that the data servers have > to support SECINFO_NO_NAME to allow clients to figure out what to use > for a given DS filehandle. Good point. We don't support per-file security, but we do support per fsid security and the DS should follow suit. A non-pNFS NFSv4.1 mount can switch auth flavors on fsid boundaries - under the cover mount, create nfs_server with it's own rpc_clnt and a different security flavor. So what to do in the DS case where the DS exports more than one fsid, each with a different security flavor? I discussed this with Dros who is also doing some work on the SECINFO code. As a first pass, it would make sense to use the security flavor that the MDS server->client uses for DS access, and replace the single data server rpc_clnt with an array of rpc_clnts one for each flavor (sys, krb5, krb5i, krb5p) that get allocated (for the DS-only case) when first needed and cached. For the MDS + DS case this cache could also be used by the MDS nfs_server->clients. Is this what you had in mind? -->Andy > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@xxxxxxxxxx > www.netapp.com -- 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
