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: <1209367536.3243.16.camel@raven.themaw.net>
Date:	Mon, 28 Apr 2008 15:25:36 +0800
From:	Ian Kent <raven@...maw.net>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	autofs mailing list <autofs@...ux.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] autofs4 - use lookup access intent to support
	recursive bind mounts


On Mon, 2008-04-28 at 08:05 +0100, Al Viro wrote:
> On Mon, Apr 28, 2008 at 02:38:25PM +0800, Ian Kent wrote:
> > 
> > On Mon, 2008-04-28 at 07:22 +0100, Al Viro wrote:
> > > On Mon, Apr 28, 2008 at 02:14:54PM +0800, Ian Kent wrote:
> > > > 
> > > > Hi Andrew,
> > > > 
> > > > For autofs maps that recursively reference other map entries in their
> > > > mount point path we need to ensure that these mounts are performed
> > > > prior to the current mount request being done. We've used the access
> > > > system call, made just prior to performing the mount, to make this
> > > > happen. In the case of bind mounts, however, the lookup flags in 
> > > > the path walk don't trigger a mount. To do this we need to also
> > > > trigger a mount when we see the LOOKUP_ACCESS flag.
> > > 
> > > That's too fscking bad, since ->lookup() is about to lose access to
> > > nameidata *and* flags for anything but the last step.  IOW, we'll need
> > > cleaner solution...
> > 
> > Spell it out for me please!
> 
> ->lookup() and friends are going to stop getting struct nameidata *.
> ->follow_link() obviously will keep it; ->d_revalidate() should
> lose the sucker, but we might have to split it in two methods (which
> is probably what'll be needed in your case).

Right.

I don't see that yet in 2.6.25-mm1, are there any preliminary patches I
could look at?

> 
> At the same time struct open_intent is going to die, BTW, but that
> won't matter for autofs, AFAICT.

Yep, autofs doesn't care about this, it only cares about being able to
ask userspace to try a mount when needed.

Actually, using the flags to decide when to call back the daemon
wouldn't be needed at all except for mount storms caused by aggressive
GUI file system scanning and color ls and the like. 

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ