linux-kernel - Re: [PATCH] vfs: automount should ignore LOOKUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1315539207.3952.41.camel@perseus.themaw.net>
Date:	Fri, 09 Sep 2011 11:33:27 +0800
From:	Ian Kent <raven@...maw.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	David Howells <dhowells@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Leonardo Chiquitto <leonardo.lists@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>, autofs@...ux.kernel.org
Subject: Re: [PATCH] vfs: automount should ignore LOOKUP_FOLLOW

On Thu, 2011-09-08 at 10:42 -0700, Linus Torvalds wrote:
> On Thu, Sep 8, 2011 at 6:38 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
> >
> > Yes, 2.6.38 and later kernels do trigger on stat(2) but not on lstat(2).
> >
> > My question is this:  does this behavior improve anything compared to
> > kernels before 2.6.38?  Because I don't see that it does, in fact it's
> > just causing regressions.
> >
> > You say it's a step in the right direction but I don't see why.  Either
> > we want stat *and* lstat to both be correct and trigger the automount or
> > we are satisfied with the incorrect but well established practice of not
> > triggering on (l)stat.
> >
> > The middle ground makes no sense IMO, there's nothing gained by the
> > differentiated behavior based on LOOKUP_FOLLOW.
> >
> > Can you explain why it's better if stat() tiggers automounts and gives a
> > correct result but lstat() doesn't?
> 
> I have to say that this is a very cogent question.
> 
> The one thing I've not seen in the thread yet is a description of the
> failure. What does the regression look like? Just "very slow 'ls' with
> some versions of 'ls'" or what?

The problem that is seen is everything in a directory being mounted upon
listing the directory. This isn't really a problem for small automount
maps but maps with more than a few dozen entries start becoming
problematic and a few hundred entries or more (quite common in many
environments) is an obvious nightmare.

Clearly this is a problem that I have introduced by the idea of the
"browse" option of autofs, whereby the potential automount points of an
indirect automount are visible within the automount managed directory
but it also applies to NFS crossing mount points (since those mount
point directories must also pre-exist).

Note that this isn't as problem if the "browse" option isn't used since
we just se an empty directory and specific access to a path causes only
those mounts to occur. But Solaris has been able to do this for years
now so it is expected by the user community.

> 
> I'm inclined to apply the patch as a regression fix, but I'll let this
> thread try to convince me for another day..

I have to agree, although it would be good to get some input from other
subsystem maintainers.

Ian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/