Subject: [nfsv4] [PATCH 0/4] Do not use a RPC cred for fencing users

From: Thomas Haynes <[email-masked]>
Date: Mon, 19 Jan 2015 13:31:41 -0800

From: Tom Haynes <[email-masked]>

This patch set changes the RPC credential used for fencing into an
fattr4_owner and fattr4_owner_group.

Tom Haynes (4):
  Define the protocols to the storage device, not the metadata server
  Fix the RPC xref
  Expound more on the generation of synthetic ids
  Explain format of user and group strings

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 19 Jan 2015 13:31:43 -0800

Signed-off-by: Tom Haynes <[email-masked]>
---
 flexfiles_middle_coupling.xml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/flexfiles_middle_coupling.xml b/flexfiles_middle_coupling.xml
index 89f5244..098f070 100644
--- a/flexfiles_middle_coupling.xml
+++ b/flexfiles_middle_coupling.xml
@@ -45,7 +45,8 @@
       gid owner is allowed read only access.  As part of the layout
       (see ffds_user and ffds_group in  <xref target='ff_layout4' />),
       the client is provided with the user and group to be used in
-      the RPC credentials needed to access the data file.  Fencing
+      the Remote Procedure Call (RPC) <xref target='RFC5531' />
+      credentials needed to access the data file.  Fencing
       off clients is achieved by using SETATTR by the server to
       change the uid and/or gid owners of the data file to implicitly
       revoke the outstanding rpc credentials.
-- 
1.9.3

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 19 Jan 2015 13:31:44 -0800

Signed-off-by: Tom Haynes <[email-masked]>
---
 flexfiles_middle_coupling.xml | 45 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/flexfiles_middle_coupling.xml b/flexfiles_middle_coupling.xml
index 098f070..d8e039c 100644
--- a/flexfiles_middle_coupling.xml
+++ b/flexfiles_middle_coupling.xml
@@ -49,7 +49,16 @@
       credentials needed to access the data file.  Fencing
       off clients is achieved by using SETATTR by the server to
       change the uid and/or gid owners of the data file to implicitly
-      revoke the outstanding rpc credentials.
+      revoke the outstanding RPC credentials.
+    </t>
+
+    <t>
+      With this loosely coupled model, the metadata server is 
+      not able to fence off a single client, it forced to fence
+      off all clients. However, as the other clients react to
+      the fencing, returning their layouts and trying to get
+      new ones, the metadata server can hand out a new uid and
+      gid to allow access.
     </t>
 
     <t>
@@ -73,6 +82,40 @@
       same authorization process it would go through via the metadata
       server.
     </t>
+
+    <section title='Implementation Notes for Synthetic uids/gids'>
+      <t>
+        The selection method for the synthetic uids and gids to
+        be used for fencing in loosely coupled storage devices
+        is strictly an implementation issue. An implementation
+        might allow an administrator to restrict a range of such
+        ids in the name servers.  She might also be able to
+        choose an id that would never be used to grant acccess.
+        Then when the metadata server had a request to access
+        a file, a SETATTR would be sent to the storage device
+        to set the owner and group of the data file. The user
+        and group might be selected in a round robin fashion
+        from the range of available ids.
+      </t>
+
+      <t>
+        Those ids would be sent back as ffds_user and ffds_group
+        to the client. And it would present them as the RPC
+        credentials to the storage device. When the client was
+        done accessing the file and the metadata server knew
+        that no other client was accessing the file, it could
+        reset the owner and group to restrict access to the
+        data file.
+      </t>
+
+      <t>
+        When the metadata server wanted to fence off a client,
+        it would change the synthetic uid and/or gid to
+        the restricted ids. Note that using a restricted id
+        ensures that there is a change of owner and at least
+        one id available that never gets allowed access.
+      </t>
+    </section>
   </section>
 
   <section title="State and Locking Models">
-- 
1.9.3

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 19 Jan 2015 13:31:42 -0800

Signed-off-by: Tom Haynes <[email-masked]>
---
 flexfiles_middle_introduction.xml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/flexfiles_middle_introduction.xml b/flexfiles_middle_introduction.xml
index cc813c1..0bb8dcc 100644
--- a/flexfiles_middle_introduction.xml
+++ b/flexfiles_middle_introduction.xml
@@ -63,8 +63,7 @@
 
         <t hangText='File Layout Type:'>
           is a Layout Type in which the storage devices
-          are accessed via the NFSv4.1 protocol. It is
-          defined in Section 13 of <xref target='RFC5661' />.
+          are accessed via the NFS protocol.
         </t>
 
         <t hangText='layout:'>
-- 
1.9.3

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 19 Jan 2015 13:31:45 -0800

Signed-off-by: Tom Haynes <[email-masked]>
---
 flexfiles_middle_layout.xml | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/flexfiles_middle_layout.xml b/flexfiles_middle_layout.xml
index 511b6b2..caa46ea 100644
--- a/flexfiles_middle_layout.xml
+++ b/flexfiles_middle_layout.xml
@@ -202,6 +202,20 @@
     </t>
 
     <t>
+      The allowed values for both ffds_user and ffds_group are
+      specified in Section 5.9 of <xref target='RFC5661' />.  For
+      NFSv3 compatibility, user and group strings that consist of
+      decimal numeric values with no leading zeros can be given a
+      special interpretation by clients and servers that choose to
+      provide such support.  The receiver may treat such a user or
+      group string as representing the same user as would be
+      represented by an NFSv3 uid or gid having the corresponding
+      numeric value. Note that if using Kerberos for security,
+      the expectation is that these values will be a name@domain
+      string.
+    </t>
+
+    <t>
       ffds_efficiency describes the metadata server's evaluation
       as to the effectiveness of each mirror. Note that this is per
       layout and not per device as the metric may change due to
-- 
1.9.3

---

From: Benny Halevy <[email-masked]>
Date: Wed, 21 Jan 2015 13:58:34 +0200

Ack,

Benny

On Jan 19, 2015 11:31 PM, "Thomas Haynes" <[email-masked]>
wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4