Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265671AbTFSOSE (ORCPT ); Thu, 19 Jun 2003 10:18:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265673AbTFSOSE (ORCPT ); Thu, 19 Jun 2003 10:18:04 -0400 Received: from pub237.cambridge.redhat.com ([213.86.99.237]:46054 "EHLO warthog.warthog") by vger.kernel.org with ESMTP id S265671AbTFSOSA (ORCPT ); Thu, 19 Jun 2003 10:18:00 -0400 To: Mike Waychison cc: David Howells , viro@parcelfarce.linux.theplanet.co.uk, David Howells , Linus Torvalds , Kernel Mailing List Subject: Re: [PATCH] VFS autmounter support v2 In-Reply-To: Message from Mike Waychison of "Thu, 19 Jun 2003 10:00:40 EDT." <3EF1C208.1080404@sun.com> User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Jun 2003 15:31:46 +0100 Message-ID: <11504.1056033106@warthog.warthog> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2791 Lines: 62 > > Then have a daemon that can take a request to mount and then reply with > > the mount parameters, allowing the trap fs to obtain a vfsmount via > > do_kern_mount(). I would make the trap fs supply the daemon with an fd > > attached to the trap rootdir to act as a token representing the request > > (and controlling its lifetime). > > > > You would have to go this route. I think Al's opinion in this is that > your original proposal allows arbitrary dentry's in the tree to act as > traps. As such, there is no way for a derived namespace to manipulate > that trap at all. > By implying that the trap is installed via mount says you are now proposing > that every trap is represented by its own superblock. This is more or less what Al suggested, except that he suggested "traps" are special vfsmounts that don't have superblocks, dentries, and inodes. > You're new proposal is exactly what I have been working on, autofs > direct mountpoints using the less intrusive follow_link magic Anvin has > mentioned on a previous thread both here and on autofs@vger. > > The one problem with this solution is the following breaks: > > # installtrap /foo host:/export/foo > > # newnssh > newnssh # cd /foo > > Oops, the daemon started from the initial namespace doesn't have access > to the namespace in my second shell. Yes. You can see that happening now with autofs and amd. However it does work with my suggestion because the "automounter" code just returns a namespace independent vfsmount, which the VFS can then bind into the appropriate namespace and the appropriate place. > The most reasonable way I can see to cope with this is to allow > CAP_SYS_ADMIN processes the ability to change namespaces. Eg, the > daemon can be told which pid triggered the trap on /foo, > open(/proc//mounts) and perform a ioctl(IOC_USENAMESPACE) on it. > > What do you guys think? I think a better way is for the kernel to pass the daemon a file descriptor attached to the mount point. This would then act as a token representing the request, and as such it automatically includes the mount point info (struct file has vfsmount/dentry pointers) and can also be used to manage the lifetime of the request. I'd then make there be either a "mount" ioctl/fcntl on that fd that uses the info stored on the struct file, or perhaps provide an "fmount" syscall (but you have to be careful - otherwise someone can use an arbitrary cross-namespace fd to mangle some other namespace). David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/