From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Van Hensbergen Subject: [RFC] User CLONE_NEWNS permission and rlimits Date: Tue, 19 Apr 2005 20:24:37 -0500 Message-ID: Reply-To: Eric Van Hensbergen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: Received: from wproxy.gmail.com ([64.233.184.194]:55205 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S261202AbVDTBYl convert rfc822-to-8bit (ORCPT ); Tue, 19 Apr 2005 21:24:41 -0400 Received: by wproxy.gmail.com with SMTP id 69so18751wra for ; Tue, 19 Apr 2005 18:24:37 -0700 (PDT) To: linux-fsdevel@vger.kernel.org, Al Viro Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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? -eric