From: Ian Kent <raven@themaw.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
David Howells <dhowells@redhat.com>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
Jeff Layton <jlayton@redhat.com>,
viro@zeniv.linux.org.uk, gregkh@suse.de,
linux-nfs@vger.kernel.org, leonardo.lists@gmail.com
Subject: Re: [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc.
Date: Sat, 24 Sep 2011 10:31:20 +0800 [thread overview]
Message-ID: <1316831480.3346.178.camel@perseus.themaw.net> (raw)
In-Reply-To: <CA+55aFwPEq5B_P0RtX+pBtGfTadzzS+3U=k=3XTjDw3soNhOdA@mail.gmail.com>
On Fri, 2011-09-23 at 18:44 -0700, Linus Torvalds wrote:
> On Fri, Sep 23, 2011 at 6:30 PM, Ian Kent <raven@themaw.net> 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
next prev parent reply other threads:[~2011-09-24 2:31 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-22 13:45 [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc David Howells
2011-09-22 14:33 ` Miklos Szeredi
2011-09-22 16:04 ` Ian Kent
2011-09-22 16:30 ` Linus Torvalds
2011-09-22 16:45 ` Ian Kent
2011-09-22 17:35 ` Jeff Layton
2011-09-22 18:44 ` Jeff Layton
2011-09-22 19:20 ` Trond Myklebust
2011-09-22 22:57 ` Linus Torvalds
2011-09-23 0:56 ` Myklebust, Trond
2011-09-23 1:04 ` Linus Torvalds
2011-09-23 1:21 ` Trond Myklebust
2011-09-23 7:25 ` Miklos Szeredi
2011-09-23 10:57 ` Ian Kent
2011-09-23 3:15 ` Ian Kent
2011-09-23 10:33 ` David Howells
2011-09-23 14:34 ` Trond Myklebust
2011-09-23 14:46 ` Linus Torvalds
2011-09-23 15:01 ` Trond Myklebust
2011-09-23 15:15 ` Linus Torvalds
2011-09-23 15:41 ` Ian Kent
2011-09-23 16:19 ` Miklos Szeredi
2011-09-23 16:21 ` Linus Torvalds
2011-09-23 16:26 ` Linus Torvalds
[not found] ` <13920.1316796007@redhat.com! >
2011-09-23 16:54 ` David Howells
2011-09-23 17:18 ` Linus Torvalds
2011-09-23 16:40 ` David Howells
2011-09-23 16:47 ` Linus Torvalds
2011-09-23 15:18 ` David Howells
2011-09-23 16:10 ` Miklos Szeredi
2011-09-24 1:30 ` Ian Kent
2011-09-24 1:44 ` Linus Torvalds
2011-09-24 2:31 ` Ian Kent [this message]
2011-09-24 11:36 ` Jeff Layton
2011-09-24 15:56 ` Linus Torvalds
2011-09-26 5:11 ` Ian Kent
2011-09-26 20:48 ` Linus Torvalds
2011-09-26 21:13 ` Trond Myklebust
2011-09-26 21:24 ` Linus Torvalds
2011-09-26 21:31 ` Trond Myklebust
2011-09-26 22:24 ` Linus Torvalds
2011-09-26 22:33 ` Trond Myklebust
2011-09-26 22:56 ` Linus Torvalds
2011-09-26 23:09 ` Trond Myklebust
2011-09-26 23:26 ` Linus Torvalds
2011-09-27 0:59 ` Trond Myklebust
2011-09-27 1:18 ` Linus Torvalds
2011-09-27 4:24 ` Ian Kent
2011-09-27 3:57 ` Linus Torvalds
2011-09-27 4:16 ` Ian Kent
2011-09-27 4:35 ` Linus Torvalds
2011-09-27 4:51 ` Ian Kent
2011-09-27 14:32 ` Linus Torvalds
2011-09-27 15:11 ` Myklebust, Trond
2011-09-29 9:32 ` Ian Kent
2011-09-27 15:22 ` Linus Torvalds
2011-09-27 17:38 ` Greg KH
2011-09-27 17:51 ` Linus Torvalds
2011-09-27 18:00 ` Greg KH
2011-09-27 20:18 ` Miklos Szeredi
2011-09-27 22:38 ` Greg KH
2011-09-27 13:34 ` [PATCH 1/2] VFS: Fix the remaining automounter semantics regressions Trond Myklebust
2011-09-27 13:34 ` [PATCH 2/2] VFS: Document automounter semantics Trond Myklebust
2011-09-23 15:23 ` [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc David Howells
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=1316831480.3346.178.camel@perseus.themaw.net \
--to=raven@themaw.net \
--cc=Trond.Myklebust@netapp.com \
--cc=dhowells@redhat.com \
--cc=gregkh@suse.de \
--cc=jlayton@redhat.com \
--cc=leonardo.lists@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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).