On Nov 3, 2013, at 12:01, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Sun, 3 Nov 2013 16:40:12 +0000 > "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > >> >> On Nov 3, 2013, at 6:01, Jeff Layton <jlayton@xxxxxxxxxx<mailto:jlayton@xxxxxxxxxx>> wrote: >> >> On Sun, 3 Nov 2013 05:14:38 -0500 >> Jeff Layton <jlayton@xxxxxxxxxx<mailto:jlayton@xxxxxxxxxx>> wrote: >> >> On Sun, 3 Nov 2013 02:23:29 +0000 >> "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx<mailto:Trond.Myklebust@xxxxxxxxxx>> wrote: >> >> >> On Nov 2, 2013, at 6:57, Jeff Layton <jlayton@xxxxxxxxxx<mailto:jlayton@xxxxxxxxxx>> wrote: >> >> Currently, we fetch the security label when revalidating an inode's >> attributes, but don't apply it. This is in contrast to the readdir() >> codepath where we do apply label changes. >> >> OK. Why should we not just throw out the code that fetches the security label here? >> >> IOW: what is the caching model that is being implemented in this patch; is it just “fetch label at random intervals” or is there real method to the madness? >> >> Trond >> >> I think that we should apply the new security label as soon as we >> realize that it has changed. Why should we treat the security label >> differently from any other inode attribute (e.g. ownership or mode)? >> >> >> Ok, I think I understand what you're getting at now that I've had a cup >> of coffee ;) >> >> I guess you're pointing out a problem with the overall model, given that >> the current implementation doesn't send anything in the RPC to denote >> the security context of the client's task? >> >> It's a fair point, and not one I have a great answer for. I think that >> you're correct that for the most part that they won't change. But when >> they do, what's to be gained by ignoring that? >> >> They'll never be permanent anyway...as soon as the inode gets tossed >> out of the cache or the client reboots then you'll see the change on >> the next access of it. >> >> I’m not saying that we must ignore changes, I’m saying that nobody else, so far, has been willing to step up and propose a model for how these things are supposed to change. >> >> All I’ve heard has been that “a polling model would be better because labels can change”. OK, but a polling model has a number of adjustable parameters; the frequency of polling being the most obvious. I want someone to explain to me, based on how we expect labels to change, how those parameters need to be set. >> If the expectation is that they will change once in a lifetime (just after file creation), then that would justify trying to poll once or twice, but it does not justify polling for the entire lifetime of the file. Perhaps a better solution would be to just have the server change the NFS filehandle (e.g. by bumping the generation counter)? >> > > Ugh...that sounds ugly and prone to cause ESTALE errors. > > I don't think we can make any assumption on how they will change, any > more than we do for something like the ownership or mode. It comes down > to an action by an administrator, and people are notoriously > unpredictable. ???? You’re saying that people choose security policies on a whim? > Maybe this is a naive question, but...why treat this differently from > any other inode attribute? That’s another “What if we were to do X?” question. Please see above. Trond-- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
