Subject: [nfsv4] Changes for change_sec_label

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 15 Oct 2012 19:41:26 +0000

loghyr:NFSv4.2 thomas$ git diff
diff --git a/dotx.d/spit_types.sh b/dotx.d/spit_types.sh
index 093be2a..e9152c0 100755
--- a/dotx.d/spit_types.sh
+++ b/dotx.d/spit_types.sh
@@ -1425,7 +1425,7 @@ EOF
 
 cat << EOF > $i
 
-typedef uint32_t       change_sec_label4;
+typedef uint64_t       change_sec_label4;
 EOF
 
        ;;
diff --git a/nfsv42_middle_fileattributes.xml b/nfsv42_middle_fileattributes.xml
index 057bd77..86d5cb3 100644
--- a/nfsv42_middle_fileattributes.xml
+++ b/nfsv42_middle_fileattributes.xml
@@ -190,6 +190,12 @@ typedef uint32_t  policy4;
         that is sized correctly. By both client and server being part
         of a specific MAC model, the client will be aware of the size.
       </t>
+
+      <t>
+        If a server supports sec_label, then it MUST also support
+        change_sec_label. Any modification to sec_label MUST modify
+        the value for change_sec_label.
+      </t>
     </section>
 
     <section toc='exclude' anchor='ss:fattr:chsec' title='Attribute 81: change_sec_label'>
@@ -197,9 +203,12 @@ typedef uint32_t  policy4;
 
       <t>
         The change_sec_label attribute is a read-only attribute per file.
-        When the file is created, the value of change_sec_label is set
-        to 0. Each time the sec_label is changed, the server MUST
-        increment the value of change_sec_label by one. As the
+        If the value of sec_label for a file is not the same at two
+        disparate times then the values of change_sec_label at those
+        times MUST be different as well.  The value of change_sec_label
+        MAY change at other times as well, but this should be rare, as
+        that will require the client to abort any operation in progress,
+        re-read the label, and retry the operation.  As the
         sec_label is not bounded by size, this attribute allows for
         VERIFY and NVERIFY to quickly determine if the sec_label
         has been modified.

Comments?

---

From: "Noveck, David" <[email-masked]>
Date: Mon, 15 Oct 2012 16:55:52 -0400

I doubt that 64 bits are enough for a hashing implementation given the MUST's.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Monday, October 15, 2012 3:41 PM
To: nfsv4 list
Subject: [nfsv4] Changes for change_sec_label

 cat << EOF > $i

        ;;

       <t>

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 15 Oct 2012 22:15:07 +0000

> I doubt that 64 bits are enough for a hashing implementation given the MUST's.

I don't want to play the game where I bump until someone stops replying.

I don't think a straight hash works at all - collisions are bad not only with
your last value, but the one before that. I.e., change the value enough times
in a short period and a client might not be able to detect any change.

Why doesn't using a nfstime4 solve the problem?

The value would be the last time the sec_label was modified.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Mon, 15 Oct 2012 22:31:43 +0000

> The value would be the last time the sec_label was modified.

The main problem is that it requires permanent storage for a timestamp.
Bruce objected to forcing the filesystem to provide additional storage
for attributes.

OTOH, any Linux server that supports labeled NFS by storing the labels
in an xattr will also be capable of storing the timestamp in a similar
xattr.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 15 Oct 2012 22:51:46 +0000

> in an xattr will also be capable of storing the timestamp in a similar

Since it only applies to OPEN files, why not define it as the time since
the last sec_label change since it was first opened. If the value is 0, it
means it was just opened and should be considered a change. If
the server is presented a FH without the file being in an open state,
it returns a 0 for the attribute, which tells the client to get the sec_label.

client A opens the file; change_sec_label is set to 0
client B opens the file 2 seconds later; change_sec_label is still 0.
client C opens the file as well; still 0
client B changes the sec_label; value of change_sec_label is about 3.00s
client A checks, gets the new sec_label value,
  and changes the sec_label back to the original, value is about 3.01s
client C checks, determines it needs to get sec_label
client A checks, determines it needs to get sec_label
client A changes it again, value is about 3.03s
client B checks, determines it needs to get sec_label, finds out it has lost access to file
client C checks, determines it needs to get sec_label, proceeds

client A closes the file
client C closes the file

server frees all information from memory

client D opens the file, change_sec_label is set to 0

and so on

---

From: "Myklebust, Trond" <[email-masked]>
Date: Mon, 15 Oct 2012 23:06:54 +0000

> client D opens the file, change_sec_label is set to 0

That means the client needs to retrieve the sec_label on every new open.
For a frequently used library, that could be extremely painful...

NetApp

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 15 Oct 2012 23:20:03 +0000

On Oct 15, 2012, at 6:06 PM, "Myklebust, Trond" <[email-masked]> wrote:

> For a frequently used library, that could be extremely painful…
> 

Odds are some client would have it open.

Or convince Bruce to store it in the xinode :-> - i.e., either it is
persistent or uses the above algorithm.

Or use a hash that fits into the 96 bits available for a nfstime4. The first
64 are the hash and the remaining 32 are a generation number to prevent frequent reuse.

And those are all implementation suggestions.

32 bits and 64 bits are claimed to be insufficient.

I'm going to claim that 96 bits are sufficient for an approach I would take. Any
hashers out there got an issue with that?

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 16 Oct 2012 15:35:11 -0400

> Bruce objected to forcing the filesystem to provide additional storage

I didn't intend to object.

> in an xattr will also be capable of storing the timestamp in a similar

Making sure it's updated in the right places is probably more annoying
than finding a place to put it.

Looking at e.g.
http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions,
typical crytographic hash sizes are 128-256 bytes.  Is that too much?

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 16 Oct 2012 19:45:51 +0000

> typical crytographic hash sizes are 128-256 bytes.  Is that too much?

I've got it at 128 right now. 

We could just make it opaque<> and let the server do with it what it will.

Since we are not mandating the contents (like say a timestamp), then why
should we mandate the size?

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 16 Oct 2012 20:25:02 +0000

>> typical crytographic hash sizes are 128-256 bytes.  Is that too much?

By the way, a hashee has told me off list that these are way too
expensive. Why not http://code.google.com/p/cityhash/ ?

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 16 Oct 2012 16:40:58 -0400

On Tue, Oct 16, 2012 at 08:25:02PM +0000, Haynes, Tom wrote:
> expensive.

Well, you'd cache the result, but: could be.  The hash would probably be
longer than the original label in a lot of cases too.

> Why not http://code.google.com/p/cityhash/ ?

I don't know, maybe that'd be good enough depending on how labels are
chosen.

--b.

---

From: "Black, David" <[email-masked]>
Date: Tue, 16 Oct 2012 18:00:22 -0400

> > >> typical cryptographic hash sizes are 128-256 bytes.  Is that too much?

That's 128-256 bits, *not* bytes.  SHA2-256 (256 bits [32 bytes]) is a good choice for new work.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.
> Bruce Fields
> Sent: Tuesday, October 16, 2012 4:41 PM
> To: Haynes, Tom
> Cc: Myklebust, Trond; nfsv4 list
> Subject: Re: [nfsv4] Changes for change_sec_label
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 16 Oct 2012 19:14:02 -0400

> That's 128-256 bits, *not* bytes.  SHA2-256 (256 bits [32 bytes]) is a good choice for new work.

Doh, of course you're right, thanks.

--b.