Subject: [nfsv4] [NFSv4.2] Meeting Minutes for 09/22/2011

From: Thomas Haynes <[email-masked]>
Date: Thu, 22 Sep 2011 22:25:47 -0700

Attendees
--------------

- Tom Haynes (NetApp)
- Manjunath Shankararao (NetApp)
- Viswanath Bandi (NetApp)
- Dean Hildebrand (IBM)
- Trond Myklebust (NetApp)
- Peter Staubach (EMC)
- Rob Thurlow (Oracle)
- Chuck Lever (Oracle)
- Steve Dickson (RedHat)
- Andy Adamson (NetApp)

+ IETF Note Well Agreement

   http://www.ietf.org/NOTEWELL.html

+ LNFS Requirements Spec

Dave expects to have this ready by the end of the month.

+ Mismatch between OPEN/share modes and actual permissions

Can have READ and WRITE modes, but not EXEC.

AI: Trond to propose 4.0/4.1 implementation text to the WG alias and what we can do in 4.2.

+ IO_ADVISE

Dean summarized Mike's new text. 

He had some questions about dense versus sparse.

He will fold the new text into their draft and create a new version.

+ seek_hole and seek_data

Trond still looking at use cases

Dean had reviewed them as well - big differentiator between space maps and this is that the
intent the data is relevant.

Tom pointed out READ_PLUS could almost do this, but returning actual data is problematic.

Tom will propose some strawman XDR to the list.

Allocated versus unallocated on sparse blocks. This came up at the Spencer's SDC presentation.

Say we have a block of all zeros and decide to send a hole back instead of a block of zeros. Is
it useful to indicate whether it is allocated versus unallocated?

This allows for example the detection of allocated data which can be hole punched. During a copy
it allows a hole on the destination, etc.

We'll add this to the next draft.

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 23 Sep 2011 16:32:09 -0400

> AI: Trond to propose 4.0/4.1 implementation text to the WG alias and

Please see the attached patch for a suggested change to RFC3530bis that
documents the problem and suggests the obvious solution of using the
ACCESS operation after OPENing the file.

For NFSv4.2 I suggest that we we add two new OPEN share modes:

      * OPEN4_SHARE_ACCESS_READ_DATA would grant access if the
        credential has read rights to the file, and the server can grant
        a read share lock. 
      * OPEN4_SHARE_ACCESS_EXECUTE would grant access if the credential
        has execute rights to the file, and the server can grant a read
        share lock.

Then we can deprecate the OPEN4_SHARE_ACCESS_READ mode, and perhaps
remove it altogether in NFSv4.3?

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

From 307d6dfb3dd499eb72f2c00a055ccd75e07038d1 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <[email-masked]>
Date: Fri, 23 Sep 2011 16:19:15 -0400
Subject: [PATCH] Clients should use ACCESS to distinguish between read and
 execute rights

Document that the OPEN operation is incapable of distinguishing between
a client's attempt to open the file for reading and opening it in order
to execute the contents.

Signed-off-by: Trond Myklebust <[email-masked]>
---
 nfsv4_middle_file_locking.xml |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/nfsv4_middle_file_locking.xml b/nfsv4_middle_file_locking.xml
index 6d60b5d..ac5ab9f 100644
--- a/nfsv4_middle_file_locking.xml
+++ b/nfsv4_middle_file_locking.xml
@@ -2105,6 +2105,19 @@
     </t>
 
     <t>
+      Although the OPEN operation will do access permission checking
+      based on the share mode argument, it is worth noting that
+      it cannot distinguish between read and execute access modes.
+      The server SHOULD grant a request for OPEN4_SHARE_ACCESS_READ
+      provided that the user credential presented by the client has
+      read or execute rights to the file and there are no conflicting
+      deny share locks in effect.
+      After being granted the OPEN request, the client SHOULD use
+      the ACCESS operation to determine whether or not to allow or
+      deny read and execute rights to the application.
+    </t>
+
+    <t>
       The OPEN operation with the CREATE flag, also subsumes the CREATE
       operation for regular files as used in previous versions of the NFS
       protocol.  This allows a create with a share to be done atomically.
-- 
1.7.6.2

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 27 Sep 2011 09:24:17 -0500

Also, since we have a window to take the UDP changes, does anyone object to the
following changes from Trond to help mitigate the lack of a OPEN4_SHARE_ACCESS_EXECUTE?

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Sep 2011 13:43:54 -0400

> following changes from Trond to help mitigate the lack of a OPEN4_SHARE_ACCESS_EXECUTE?

Looks fine to me.

--b.