Subject: [nfsv4] 4.2 label xdr bug

From: [email-masked] (J. Bruce Fields)
Date: Thu, 30 Jul 2015 11:53:30 -0400

This is confusing--the label attribute isn't an array.  And why does the
.x have two definitions of sec_label4?

Maybe something like the below is better?

(Thanks to Kinlong Mee for spotting this.)

--b.

diff --git a/dotx.d/head.x b/dotx.d/head.x
index 85fb741..3db96ff 100644
--- a/dotx.d/head.x
+++ b/dotx.d/head.x
@@ -501,7 +501,6 @@ typedef change_policy4	fattr4_change_policy;
 typedef uint64_t	fattr4_space_freed;
 typedef change_attr_type4
 		fattr4_change_attr_type;
-typedef sec_label4	fattr4_sec_label<>;
 typedef uint32_t	fattr4_clone_blksize;
 
 %/*
diff --git a/nfsv42_middle_fileattributes.xml b/nfsv42_middle_fileattributes.xml
index c2da218..810e5cd 100644
--- a/nfsv42_middle_fileattributes.xml
+++ b/nfsv42_middle_fileattributes.xml
@@ -196,8 +196,8 @@ typedef uint32_t  policy4;
       </t>
 
       <t>
-        The FATTR4_SEC_LABEL contains an array of two components with the first
-        component being an LFS.  It serves to provide the receiving end
+        The first field of the FATTR4_SEC_LABEL is an LFS, which
+        serves to provide the receiving end
         with the information necessary to translate the security attribute
         into a form that is usable by the endpoint.  Label Formats assigned
         an LFS may optionally choose to include a Policy Identifier
@@ -206,7 +206,7 @@ typedef uint32_t  policy4;
         <xref target='Quigley14' />.
         The translation used to interpret the security
         attribute is not specified as part of the protocol as it may depend
-        on various factors.  The second component is an opaque section which
+        on various factors.  The second field is an opaque section which
         contains the data of the attribute.  This component is dependent on
         the MAC model to interpret and enforce.
       </t>

---

From: Tom Haynes <[email-masked]>
Date: Thu, 30 Jul 2015 09:50:56 -0700

> On Jul 30, 2015, at 8:53 AM, J. Bruce Fields <[email-masked]> wrote:
> 
> This is confusing--the label attribute isn't an array.

Why isn’t it?

Is that an artifact of seLinux?

Look at Section 1.4.6, which defines labels on files.

FWIW - looking back at all of the prior documents/drafts, this has been an array from the start.

>  And why does the

Where?

skull:dotx.d loghyr$ grep sec_label4 nfsv42.x 
struct sec_label4 {
typedef sec_label4      fattr4_sec_label<>;

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 30 Jul 2015 13:34:34 -0400

> typedef sec_label4      fattr4_sec_label<>;

Gah, I just should just turn my brain in for a new one.  What's the
warranty period on these things anyway?

But, I think there's still two issues here:

	1. You're right, that attribute is in fact defined as an array.
	   But Linux client and server think it's just a single struct
	   sec_label4.  Ditto wireshark.  I don't know of any other
	   implementations.

	2. That "array of two components" language is confusing (it's
	   talking about a struct, not an array).

For #1, the implementations are deployed and I think we're stuck fixing
the draft to match them.  On the positive side, it doesn't appear that
anyone's missed having an array of labels, so maybe we can live with
this.  If it turns out somebody needs more then they can add a new
attribute.

For #2 I think the below might still be an OK fix.

--b.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 30 Jul 2015 11:15:57 -0700

> On Jul 30, 2015, at 10:34 AM, J. Bruce Fields <[email-masked]> wrote:
> 

Considering you did all 3 of them, yes, they agree.

> this.  If it turns out somebody needs more then they can add a new

No, this does not necessarily follow - you have a non-standard compliant
implementation - the spec doesn’t need to change.

So David/Jarrett, do you recall why the language to allow for multiple labels?
Is it a requirement for Trusted Solaris or smack or something else?

The proposals are:

1) Convert the requirement to be a single label on an object - do not add support for multiple labels 
2) Have FATTR4_SEC_LABEL be a singleton and add a new FATTR4_SEC_MULTI_LABEL to allow for multiple
3) Keep the requirement the same and make Linux fix deployed systems.

Ugh, my ideals on spec versus running code are coming to a head.

Instead of punting on the new attribute until the next release, can we figure
that out now?

I.e., we can throw 3 out right away. And either we take the new attribute in 4.2 or we decide to live
with the change that Bruce is proposing.

BTW:

I think the current language allows you to have multiple labels, with each
having a different LFS. I don’t think that is desired. I.e., are the labels ordered,
are they the same label, but in the different DOIs, etc?

Within an attribute for a given LFS, nothing prevents the slai_data<> from
being an union of multiple labels.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 30 Jul 2015 14:24:18 -0400

> Considering you did all 3 of them, yes, they agree.

I didn't write any of the three.  (But I probably reviewed all three, so
it's fair to blame me anyway, OK.)

> Ugh, my ideals on spec versus running code are coming to a head.

Well, hopefully understanding the motivation behind multiple labels will
make the choice more obvious.

--b.