Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757866AbYFTOun (ORCPT ); Fri, 20 Jun 2008 10:50:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753189AbYFTOue (ORCPT ); Fri, 20 Jun 2008 10:50:34 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:45724 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751904AbYFTOud (ORCPT ); Fri, 20 Jun 2008 10:50:33 -0400 Date: Fri, 20 Jun 2008 09:50:31 -0500 From: "Serge E. Hallyn" To: "Eric W. Biederman" , Dave Hansen Cc: Cedric Le Goater , Linux Containers , Andrew Morton , Linux Kernel Mailing List , Pavel Emelianov Subject: Re: [patch -mm 0/4] mqueue namespace Message-ID: <20080620145031.GA30800@us.ibm.com> References: <20071128163728.177495768@fr.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2230 Lines: 60 Quoting Eric W. Biederman (ebiederm@xmission.com): > Cedric Le Goater writes: > > > Hello ! > > > > Here's a small patchset introducing a new namespace for POSIX > > message queues. > > > > Nothing really complex a part from the mqueue filesystem which > > needed some special care > > This looks stalled. It actually isn't really - Cedric had resent it a few weeks ago but had troubles with the mail server so it never hit the lists. I think Dave made a few more changes from there and was getting ready to resend again. Dave? > I have a brainstorm that might takes a totally > different perspective on things. > > The only reason we don't just allow multiple mounts of mqueuefs to > solve this problem is because there is a kernel syscall on the path. > > If we just hard coded a mount point into the kernel and required user > space to always mount mqueuefs there the problem would be solved. > > hard coding a mount point is unfortunately violates the unix rule > of separating mechanism and policy. > > One way to fix that is to add a hidden directory to the mnt namespace. > Where magic in kernel filesystems can be mounted. Only visible > with a magic openat flag. Then: > > fd = openat(AT_FDKERN, ".", O_DIRECTORY) > fchdir(fd); > umount("./mqueue", MNT_DETACH); > mount(("none", "./mqueue", "mqueue", 0, NULL); > > Would unshare the mqueue namespace. > > Implemented for plan9 this would solve a problem of how do you get > access to all of it's special filesystems. As only bind mounts > and remote filesystem mounts are available. For linux thinking about > it might shake the conversation up a bit. It is unfortunate that two actions are needed to properly complete the unshare, and we had definately talked about just using the mount before. I forget why we decided it wasn't practical, so maybe what you describe solves it... But at least the current patch reuses CLONE_NEWIPC for posix ipc, which also seems to make sense. -serge -- 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/