On Fri, 2011-09-23 at 18:44 -0700, Linus Torvalds wrote: > On Fri, Sep 23, 2011 at 6:30 PM, Ian Kent <raven@xxxxxxxxxx> wrote: > > > > Perhaps, but that allows modules to circumvent VFS policy which is what > > allowed this situation to come up in the first place. > > So, realistically, what's the downside of just adding LOOKUP_DIRECTORY > (or LOOKUP_OPEN) to the nfs_follow_remote_path() case? I'm continuing to look at code and think about that but can't give a decent answer yet. > > And if we decide that we really *really* must never bind-mount a > automount point, we could certainly add LOOKUP_OPEN to that case too, > but my gut feel is that's a "doctor, doctor, it hurts when I put a > nail in my eye" kind of case - do we really care? Is it a sane > operation to do to begin with? I'll get to all the bits I need to look at eventually. Preventing the bind mounting an automount point is something that I wanted to be able to do for autofs. That's because there is a dependency on specific path oriented external information which means a bind mounting elsewhere is undefined. But I'm not sure yet that holds true across all automount users. I'm a bit surprised this has come up actually because I thought it was possible to do that before and after the vfs-automount changes. So it's a separate problem and I'd rather not get caught up in trying to resolve an ongoing pre-existing problem at the same time as trying to work out how to handle the current situation. > > My gut feel is that either of (or both) of > LOOKUP_OPEN/LOOKUP_DIRECTORY is a saner flag to check for than > LOOKUP_FOLLOW ever was. Let's keep LOOKUP_FOLLOW as being the "acts on > symlink or the thing it points to", and nothing else. It is hard to listen to what is being said and change direction when you have committed heavily to a way of doing things but I'm trying, ;) That's what I'm looking at doing by using the LOOKUP_DIRECTORY flag, all be it slowly, because I'm trying to listen to what is being said, think about it in relation to this, and understand the implications. Let me continue looking at code and thinking about it further for now. At the moment I fear that it won't quite cover all the cases, time will tell. Ian -- 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
