All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Haynes <thomas.haynes@primarydata.com>
To: "nfsv4 list (nfsv4@ietf.org)" <nfsv4@ietf.org>,
	Mailing List Linux NFS <linux-nfs@vger.kernel.org>
Subject: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL
Date: Sat, 26 Apr 2014 09:35:22 -0700	[thread overview]
Message-ID: <B05F63D2-8DB8-4FD3-92F9-C3A5B0A99D99@primarydata.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1903 bytes --]

In my issues file, I have:

4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to
   be?  Is seLinux going to support it?

   The Labeled NFS prototype in use does not currently support
   change_sec_label.

   In the past, we argued about how big it needed to be - we need
   to close down on this.

If we look at the current text in the NFSv4.2 draft, we see:

      The second change is to provide methods for the client to
      determine if the security label has changed. A client which
      needs to know if a label is going to change SHOULD request a
      delegation on that file. In order to change the security
      label, the server will have to recall all delegations. This
      will inform the client of the change. If a client wants to
      detect if the label has changed, it MAY use VERIFY and NVERIFY
      on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL
      has been modified.

So the first question is do we need two methods for detecting that the label
has changed?

Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt covers
how the client could use delegations to detect a label change.

To quote Trond out of context:

but that is the only option I can see for implementing a cache
consistency model for labels. Without it, the choices are:

 1) always fetch the label as part of every COMPOUND.
 2) assume the label never changes on the server.

The main use cases that have been presented for Labeled NFS on Linux
would tend to push me towards door number 2, Monty please...

So a client could assume that the label never changes the majority
of the time. Once it decides it does need to start checking for a change
in the label, it can get a delegation.

If we do need the attribute, what size does it need to be?

There has been mention of it being a hash or a timestamp.

[-- Attachment #1.2: Type: text/html, Size: 2881 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

             reply	other threads:[~2014-04-26 16:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-26 16:35 Thomas Haynes [this message]
2014-04-26 16:37 ` Resolving the fate of FATTR4_CHANGE_SEC_LABEL Thomas Haynes
2014-05-01 14:07 ` [nfsv4] " Jeff Layton
2014-05-01 14:16   ` Tom Haynes
2014-05-02 15:31     ` Tom Haynes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B05F63D2-8DB8-4FD3-92F9-C3A5B0A99D99@primarydata.com \
    --to=thomas.haynes@primarydata.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfsv4@ietf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.