Subject: [nfsv4] Request for Opinions: Structure of MAC label on the wire

From: "David P. Quigley" <[email-masked]>
Date: Wed, 09 Jun 2010 13:07:50 -0400

Hello,
   I am working on getting my Linux Labeled NFS prototype in line with
the documents we've been releasing and I am looking for suggestions
about a particular component. Initially we said that the entire
recommended attribute would be an opaque field and that the field was
broken into two sections. Now the idea is to have an identifier which
specifies the format of the label and then an opaque section that is the
label itself. With this new format does it make sense for me to come up
with a label structure whose XDR definition is a 32 bit number for the
LFS and then an opaque field with length or should I just include the 32
bit Label Format Specifier as part of the opaque field and just send it
in its entirety?

Dave

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Jun 2010 12:21:39 -0500

> bit Label Format Specifier as part of the opaque field and just send it

The two approaches are almost equivalent.  So I'd say make the type ID
explicit in XDR.  If you negotiate DOI separately then you might be able
to do away with the label format type ID completely.

---

From: "David P. Quigley" <[email-masked]>
Date: Wed, 09 Jun 2010 15:01:28 -0400

> to do away with the label format type ID completely.

So in my document I'd have an entry that looks like

struct sec_label {
	uint32_t	lfs;
	opaque		data;
}

This would be encoded on the wire as a 32 bit quantity then another
32bit quantity for the opaque length and then the opaque data? In our
existing implementation right now we treat the entire thing as one large
blob and in our xdr encoding and decoding functions we toss the length
onto the wire and then the entire blob of data. I'm assuming this is
because the XDR definition for opaque is actually a length and then the
data segment.

Dave

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Jun 2010 14:25:17 -0500

> 32bit quantity for the opaque length and then the opaque data? In our

Right.  The alternative of just an opaque field whose first four bytes
are an integer would be encoded as 4-byte length followed by the blob
whose first four bytes are an integer.  Aside from ordering of the two
items on the wire, and [depending on how you spec it] byte order for
that 4-byte integer, it's about the same.

> because the XDR definition for opaque is actually a length and then the

Yes.  That's fine.  Either way is fine.  But if you don't make the type
ID explicit then you need to specify its byte order (and signed-ness) --
don't forget!

Nico
--