On Mon, 2013-07-22 at 20:24 +0000, Adamson, Andy wrote:
> 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.
You don't want to us those rpc_clients directly in the
nfs_server->client. Instead you want to clone them, so that they can be
shut down without affecting the functioning of the nfs_client.
That said, it would be great to be able to share the same auth cache
with all rpc_clients that that talk to the same NFS server and use the
same auth flavour.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
