Subject: [nfsv4] Question about EXCLUSIVE4_1

From: "Frank Filz" <[email-masked]>
Date: Wed, 30 Sep 2015 10:54:26 -0700

Here are some statements from RFC 5661 that don't quite add up:

5.8.1.14. Attribute 75: suppattr_exclcreat

The bit vector that would set all REQUIRED and RECOMMENDED attributes
that are supported by the EXCLUSIVE4_1 method of file creation via
the OPEN operation. The scope of this attribute applies to all
objects with a matching fsid.

18.16.3. DESCRIPTION
...

In NFSv4.1, EXCLUSIVE4 has been deprecated in favor of EXCLUSIVE4_1.
Unlike EXCLUSIVE4, attributes may be provided in the EXCLUSIVE4_1
case, but because the server may use attributes of the target object
to store the verifier, the set of allowable attributes may be fewer
than the set of attributes SETATTR allows. The allowable attributes
for EXCLUSIVE4_1 are indicated in the suppattr_exclcreat
(Section 5.8.1.14) attribute. If the client attempts to set in
cva_attrs an attribute that is not in suppattr_exclcreat, the server
MUST return NFS4ERR_INVAL. The response field, attrset, indicates
both which attributes the server set from cva_attrs and which
attributes the server used to store the verifier. As described in
Section 18.16.4, the client can compare cva_attrs.attrmask with
attrset to determine which attributes were used to store the
verifier.

18.16.4. IMPLEMENTATION
...

After the client has performed a successful exclusive create, the
attrset response indicates which attributes were used to store the
verifier. If EXCLUSIVE4 was used, the attributes set in attrset were
used for the verifier. If EXCLUSIVE4_1 was used, the client
determines the attributes used for the verifier by comparing attrset
with cva_attrs.attrmask; any bits set in the former but not the
latter identify the attributes used to store the verifier. The
client MUST immediately send a SETATTR to set attributes used to
store the verifier. Until it does so, the attributes used to store
the verifier cannot be relied upon. The subsequent SETATTR MUST NOT
occur in the same COMPOUND request as the OPEN.

These bits taken together suggest that suppattr_exclcreat should NOT include
the attribute(s) used for the verifier, but it also suggests that if a
client sends those attributes on an OPEN/CREATE/EXCLUSIVE4_1 request, that
the client can determine which attributes were used for the verifier because
they will be missing from the attrset mask. On the other hand, it also
indicates that if an attribute not part of suppattr_exclcreat is set on
OPEN/CREATE/EXCLUSIVE4_1, then the server MUST respond with NFS4ERR_INVAL.

I'm wondering if in the case of the verifier attributes, they SHOULD be
accepted by the server for EXCLUSIVE4_1 even though they aren't in
suppattr_exclcreat, but of course will NOT be set and thus not set in the
attrset mask. The client can then EITHER use suppattr_exclcreat to determine
which required attributes are part of the verifier OR it can compare
cva_attrs.attrmask with attrset as described.

Frank

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: David Noveck <[email-masked]>
Date: Wed, 30 Sep 2015 15:19:34 -0400

I believe this can be addressed by clarifying the text without making
any substantive change in the protocol.  At least I hope it can.

With regard to 5.8.1.14 I'd add the following paragraph:

It should be noted that the appearance of particular attributes within this

mask is not a guarantee that they will be stored successfully when
specified as part of an EXCLUSIVE4_1 file creation.  Because

server implementations may, to conserve persistent storage space, store

a verifier in space which normally holds one of these attributes, they may

not be correctly stored after a successful file creation.  However, the

client has the information available to determine when attributes have not

been reliably stored, making a subsequent SETATTR necessary (see

Section 18.16.4 or details).

I'd rewrite the paragraph in 18.16.4 that you cite as follows:

After the client has performed a successful exclusive create, the attrset

response indicates which attributes, if any, were used to store the
verifier.  If EXCLUSIVE4 was used, the attributes set in attrset were
used for the verifier.  If EXCLUSIVE4_1 was used, the client can
determines the attributes used for the verifier by comparing attrset
with cva_attrs.attrmask; any bits set in the former but not the
latter identify the attributes used to store the verifier.  If such attributes

exist, the client MUST immediately send a SETATTR to set attributes

used to store the verifier.  Until it does so, the attributes used to store
the verifier cannot be relied upon.  The subsequent SETATTR MUST NOT
occur in the same COMPOUND request as the OPEN.

I also think the following cleanup needs to be done in the same section:

In the list of attributes disfavored for verifier use, I would delete
mode_set_masked.

Instead, the entry for mode should indicate that the mode (one piece of
data) is to be

avoided whether set by the mode attribute or the mode_set_masked attribute.

After the list I would add the following paragraph:

In cases in which the implementation possesss sufficient flexibility, it is
desirable

to avoid storing the verifier in attributes actually requested to be set by
the create

request, so as to avoid any need for a subsequent SETATTR.

On Wed, Sep 30, 2015 at 1:54 PM, Frank Filz <[email-masked]> wrote:

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

---

From: Malahal Naineni <[email-masked]>
Date: Wed, 30 Sep 2015 20:11:03 -0500

> client sends those attributes on an OPEN/CREATE/EXCLUSIVE4_1 request, that

If I understand, attributes used for verifier should not be in
suppattr_exclcreat list. If a client sends any such verifier attribute,
the server should return EINVAL.

> they will be missing from the attrset mask.

I thought it said, they won't be missing in the response attrset mask, but
rather will be missing in the create request cva_attrs.attrmask.

> On the other hand, it also