Re: [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc.

[David Howells <dhowells@redhat.com>]

Linus Torvalds <torvalds@linux-foundation.org> wrote:

> We may indeed have to revert for sanity at this point, but I have to
> say that I think the arguments have been very weak, and the logic for
> when to auto-mount and when not to seems to not really be based on any
> real logic.

Can you look over the patchset I've just posted.

It moves the policy on whether or not to suppress automount out of
follow_automount() - which is probably the wrong place for it anyway.

Depending on which patch you want to stop at it can reinstate the pre-Miklos
behaviour; reinstate the Miklos behaviour, but without the regression; or
reinstate the pre-d_automount behaviour.

> For example, I think the whole "let's consider lstat different from
> stat" model is broken. It works for symlinks, but that's because

That's a reasonable way to look at it; the difference between stat and lstat
is about handling symlinks only.  Furthermore, we have fstatat, so this isn't
really an issue - that can be given flags to let userspace decide what it
should do.

getxattr and co. are trickier because they don't have an AT_ flags form, and
it can be argued that these, lgetxattr and co. included should automount.
However, that would seriously upset ls, so I think we have to leave lgetxattr
not automounting, and so getxattr should follow.

We should consider adding an AT_ flags form of the xattr calls, but that's
another matter we can argue over later.

> So *that* is why I thought the LOOKUP_DIRECTORY flag was so nice. And
> I still suspect that if paired with LOOKUP_OPEN, it would actually be
> a complete solution that avoids the crazy issues with "random
> implementation detail" and could give us something that is both
> accessible from user space *and* something we can explain to a user
> from a logical basis.

I don't like this because it's fragile.  We're giving an implied second
meaning to LOOKUP_DIRECTORY/LOOKUP_OPEN, albeit a reasonable one.

Can we please move the policy to the pathwalk callers instead?

David