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
next 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.