From: Dave Quigley <dpquigl@davequigley.com>
To: Jeff Layton <jlayton@redhat.com>,
"Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "cye@redhat.com" <cye@redhat.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfs: fix oops when trying to set SELinux label
Date: Fri, 01 Nov 2013 22:43:38 -0400 [thread overview]
Message-ID: <527466DA.3060007@davequigley.com> (raw)
In-Reply-To: <20131101125719.38843cfb@tlielax.poochiereds.net>
On 11/1/2013 12:57 PM, Jeff Layton wrote:
> On Fri, 1 Nov 2013 16:50:00 +0000
> "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote:
>
>> On Fri, 2013-11-01 at 12:02 -0400, Jeff Layton wrote:
>>> It looks like _nfs4_get_security_label() has the same problem, but I've
>>> so far been unable to get it to be called, so I didn't patch it. It
>>> seems like getxattr does some special stuff for SELinux labels that
>>> cause them only to ever be fetched once.
>>>
>>> Is there some trick to it?
>>>
>>
>> Doesn't 'ls -Z' cause them to security label to be read again?
>>
>
> As best I can tell, security labels are set on the inode when the inode
> is instantiated, and then are reset on changes (i.e. setxattr). If
> another client changes the label though, it's not clear to me how your
> client would ever notice it until the inode is dropped from the cache.
>
> ISTR Eric Paris explaining to me that they do that for performance
> reasons but it seems like something that needs to be reconsidered in
> light of labeled NFS. Not picking up a security label change seems like
> a bug, IMO...
>
>> Either way, the fix is clearly needed, so I've added the patch, and Cced
>> stable.
>>
>
> Thanks!
>
This was the point of the original requirement for a label change
notification. Its important for us to pick up that label change when it
gets changed from another client or on the server directly. As of when
we implemented the prototype the cache invalidation for the security
attribute in NFSv4 was 5 seconds and we questioned whether or not it was
necessary to have an explicit change notification or if waiting 5
seconds was sufficient.
Dave
next prev parent reply other threads:[~2013-11-02 2:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-01 14:49 [PATCH] nfs: fix oops when trying to set SELinux label Jeff Layton
2013-11-01 16:02 ` Jeff Layton
2013-11-01 16:50 ` Myklebust, Trond
2013-11-01 16:57 ` Jeff Layton
2013-11-01 17:05 ` Myklebust, Trond
2013-11-01 17:18 ` Jeff Layton
2013-11-01 17:47 ` Myklebust, Trond
2013-11-01 17:58 ` Jeff Layton
2013-11-01 18:29 ` Myklebust, Trond
2013-11-02 11:05 ` Jeff Layton
2013-11-02 2:46 ` Dave Quigley
2013-11-02 2:43 ` Dave Quigley [this message]
2013-11-02 2:41 ` Dave Quigley
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=527466DA.3060007@davequigley.com \
--to=dpquigl@davequigley.com \
--cc=Trond.Myklebust@netapp.com \
--cc=cye@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).