Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754999AbYFTDLe (ORCPT ); Thu, 19 Jun 2008 23:11:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754334AbYFTDLQ (ORCPT ); Thu, 19 Jun 2008 23:11:16 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:47666 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753102AbYFTDLI (ORCPT ); Thu, 19 Jun 2008 23:11:08 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Cedric Le Goater Cc: Andrew Morton , Linux Containers , Linux Kernel Mailing List , Pavel Emelianov References: <20071128163728.177495768@fr.ibm.com> Date: Thu, 19 Jun 2008 20:00:51 -0700 In-Reply-To: <20071128163728.177495768@fr.ibm.com>> (Cedric Le Goater's message of "Wed, 28 Nov 2007 17:37:28 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-Exim-Connect-IP: 24.130.11.59 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Cedric Le Goater X-Spam-Relay-Country: X-Spam-Report: * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 XM_SPF_Neutral SPF-Neutral Subject: Re: [patch -mm 0/4] mqueue namespace X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on mgr1.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1547 Lines: 44 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. 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. Eric -- 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/