From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ritesh Kumar Subject: Re: [RFC] User CLONE_NEWNS permission and rlimits Date: Tue, 19 Apr 2005 23:02:53 -0400 Message-ID: References: <1113961818.4920.90.camel@localhost> Reply-To: Ritesh Kumar Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from wproxy.gmail.com ([64.233.184.200]:50524 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S261303AbVDTDCx convert rfc822-to-8bit (ORCPT ); Tue, 19 Apr 2005 23:02:53 -0400 Received: by wproxy.gmail.com with SMTP id 68so33200wri for ; Tue, 19 Apr 2005 20:02:53 -0700 (PDT) To: Ram In-Reply-To: <1113961818.4920.90.camel@localhost> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org I am new to the list so please bear with me :-) I have also be thinking about filesystem namespaces which are completely under the user's own control. I was also thinking of them being inherited and changed along the process heirarchy. So a given process is allowed to change its namespace any way it likes and map it to its parent's namespace. More importantly, I was thinking in terms of having this entire capability in the userspace itself. Instead of giving all the details right here... let me redirect you to the page where I have set up the prototype. You should be able to download the sample code (very small) and browse through it to get an idea of what I had in mind. I also have an article which explains what I was thinking. In essense, I was thinking of splitting up the conceps of 1) accessing the filesystem on the HDD/device and 2) setting up a namespace for accessing the files into two separate concepts and bringing up 2) completely in the userspace. What do you think? I would like to have feedback on the idea. http://www.cs.unc.edu/~ritesh/projects/perprocessfs.html Ritesh On 4/19/05, Ram wrote: > On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote: > > This is again related to the FUSE permission thread, but a slightly > > different idea and without a slimy hack patch. > > > > I really want to enable users to be able to create private namespaces, > > but I want to try and avoid creating a venerability by allowing them > > to abuse system resources. It looks like this can be done by adding > > RLIMIT_NEWNS as a per-user resource limit, and tracking the number of > > private namespaces a user has in the user_struct. Any time a user > > creates a private namespace (either via clone with CLONE_NEWNS) or any > > other method, this limit is checked and the per user count is > > incremented (in copy_namespace). When namespaces are cleaned up (in > > __put_namespace), the per-user count is decremented. > > > > Is this sufficient to cover any exposure? What's the correct solution > > for the shared sub-trees RFC? Should there be something similar for > > user mounts/binds? > > A new namespace in a shared subtree realm can create number-of- > private-namespaces number of mounts or binds depending on the number of > binds and mounts in the shared tree. > > for example if there were 10 shared vfsmounts in the original > namespace, a new private namespace will duplicate 10 of these, and > any mount or bind attempted in any of these vfsmounts will double the > number of mounts and binds. > > Hence probably you may want to keep a tab on the number mounts and > binds a user does, instead of keeping a tab on the number of namespaces > a user creates. > > RP > > > > > -eric > > - > > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Rationality is the fundamental limitation to all human thought.