Subject: [nfsv4] Credential to use for LAYOUTCOMMIT

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 17 Mar 2011 18:36:02 -0400

There is no text in rfc5661 concerning which credential should be used
for LAYOUTCOMMIT which may cover WRITES from multiple credentials. I
think there should be some guidance.

For LAYOUT4_NFSV4_1_FILES  I suggest there are these choices:

1) The client SHOULD use a credential used for one of the WRITEs that
the LAYOUTCOMMIT covers. But such unexpired authentication credentials
may not be present.  There is text in rfc5661 Section 10.4.1 that
discusses credential expiration when flushing unmodified data after
CLOSE.  We may want to say something similar for LAYOUTCOMMIT.

2) The server MAY allow the machine credential or SSV credential (see
Section 18.35) to send LAYOUTCOMMIT.

3) Some language concerning which credential to use if
EXCHGID4_FLAG_BIND_PRINC_STATEID is set  - just like LAYOUTRETURN.

There may be other concerns for other layout types.

-->Andy

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 18 Mar 2011 13:29:48 -0400

> There may be other concerns for other layout types.

For file layouts, what's the threat that needs to be protected against?

I suppose someone who didn't have the right to modify a file could
modify the mtime using the loca_time_modify field in a spoofed
LAYOUTCOMMIT.

(Could they also modify the file size using last_write_offset, or is
that only ever a hint to the server?)

--b.

---

From: Benny Halevy <[email-masked]>
Date: Sun, 20 Mar 2011 09:35:19 +0200

>> For LAYOUT4_NFSV4_1_FILES  I suggest there are these choices:

Why is this issue layout-type specific?

>> CLOSE.  We may want to say something similar for LAYOUTCOMMIT.

LAYOUTCOMMIT resembles COMMIT more than WRITE.
Keep in mind it holds a valid layout stateid, meaning the client must have
acquired a respective layout with LAYOUTIOMODE4_RW.

>> Section 18.35) to send LAYOUTCOMMIT.

Yup.

> that only ever a hint to the server?)

Both are hints.  LAYOUTCOMMIT is not SETATTR.
And loca_last_write_offset must fall in the layoutcommit range
for which the client must have held a RW layout.

Benny

> 
> --b.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Mike Eisler" <[email-masked]>
Date: Sun, 20 Mar 2011 14:26:46 -0700

What I think RFC5661 says results in this table

Using SP | BINC_PRINC on | credential to use
-----------------------------------------------
no       | no            | whatever
no       | yes           | cred of who sent LAYOUTGET
yes      | no            | SP cred ifLAYTCOMMIT is in spo_must_*
yes      | yes           | cred of who sent LAYOUTGET
         |               | or SP cred depending on spo_must*
---------------------------------------------------------\

The second row creates a problem for you if the cred was not based on
AUTH_SYS and that cred has expired. Tough luck; the client and server
should be using state protection.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 21 Mar 2011 09:51:33 -0400

> for which the client must have held a RW layout.

OK.  If the MDS considers only information from its backend as
authoritative when determining size and mtime, then in the file case at
least there seems barely any threat worth protecting against at all.

Maybe just adopt the paragraph at the end of 18.44.3?  That'd basically
be 2) and 3) above but not 1).

--b.