From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Subject: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call Date: Wed, 20 Apr 2005 14:09:31 -0700 Message-ID: <1114031370.4920.209.camel@localhost> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Eric Van Hensbergen , Jamie Lokier , linux-fsdevel@vger.kernel.org, Al Viro Return-path: Received: from e34.co.us.ibm.com ([32.97.110.132]:34455 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S261813AbVDTVJ5 (ORCPT ); Wed, 20 Apr 2005 17:09:57 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3KL9seE470920 for ; Wed, 20 Apr 2005 17:09:54 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3KL9sia226272 for ; Wed, 20 Apr 2005 15:09:54 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3KL9rYU014070 for ; Wed, 20 Apr 2005 15:09:54 -0600 To: Bryan Henderson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-04-20 at 11:57, Bryan Henderson wrote: > >How about making namespace's as first class objects with some associated > >name or device in the device tree having owner/permissions etc. any > >process which forks off a namespace shall create the > >device node for the namespace. If some other process wants to use > >the same namespace, it can do so by attaching itself to the namespace > >dynamically? Offcourse children processes inherit the same namespace. > For the issues being discussed here, I don't think that's materially > different from what we started with; it has the same issue concerning > whether a user should be allowed to change his namespace and whether a > process' namespace should change automatically when another process does > something. Well I am not aware of issues that can arise if a user is allowed to change to some namespace for which it has permission to switch. I am wondering what can those be. Just for clarity under the assumption that there wont be any security issues with this proposal, I will run through a typical case on how this proposal can be used to solve the FUSE needs. Ok let me explain how my proposal attempts to solves the problem: A user 'ram' creates a namespace 'n1' with a device node /dev/n1 having permission 700 owned by the user 'ram'. The user than tailors his namespace with a bunch of mount/umount/binds etc to meet his requirement. All the processes that fork off this process see this same setup. Now 'ram' again logs-in to the same machine from a different terminal. He gets the default system-namespace to begin with. But he runs a shell built-in command 'chnamespace n1' and hence forth it will hook on to the new namespace and see the same environment as seen by the other login. And this login can be automated to see the 'n1' namespace by default by making the login process to pick the 'n1' namespace right from the beginning (if one exists) by looking at the some configuration file like /etc/password or maybe /etc/shadow. Any other user who wants to attach to the same namespace can try to, but if the permissions are denied it wont be able to. > > Here's one more proposal, kind of a compromise among various previous > ones. > > - When you mount(), you say whether the names should be visible by > default or not. It takes system privilege to make them visible by > default, but an ordinary user can mount a willing filesystem over a > directory he's permitted to modify unconditionally, invisible by default > - A process can explicitly request to see an invisible-by-default > mounted filesystem. Anyone can do this, but permissions on the root > directory of the mount determine if he can actually see anything. > > - A process inherits the parent's namespace (i.e. sees the mounts the > parent does). Trying to understand your proposal to see how it could be used to solve the problem faced by the FUSE project. Are you trying to use a single namespace with invisible mounts capability? RP > > This accomplishes: > > - not much of a philosophical break from where we are now. > > - users can mount their own stuff without system privilege. > > - no one, not even a fully permitted administrative process, sees user > junk by default. > > - setuid programs see standard files where the system administrator put > them. > > - setuid programs see user files where the user put them. > > - multiple processes, with or without the same uid, can see user-mounted > files if they want. > > - a process can opt not to see user-mounted files, even if it has the > same uid as processes that do. > > I'm not saying how I would implement this; there's enough discussion over > the desired result that I thought we should start there. > > -- > Bryan Henderson IBM Almaden Research Center > San Jose CA Filesystems >