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: Thu, 21 Apr 2005 12:10:54 -0700 Message-ID: <1114110654.3856.14.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 e5.ny.us.ibm.com ([32.97.182.145]:19664 "EHLO e5.ny.us.ibm.com") by vger.kernel.org with ESMTP id S261789AbVDUTJP (ORCPT ); Thu, 21 Apr 2005 15:09:15 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3LJ9Fof004437 for ; Thu, 21 Apr 2005 15:09:15 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3LJ9Fl5076152 for ; Thu, 21 Apr 2005 15:09:15 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3LJ9E5Q032009 for ; Thu, 21 Apr 2005 14:09:15 -0500 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 17:42, Bryan Henderson wrote: > >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 think I misunderstood your proposal. > > >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. > > How does that address the setuid problem -- that a setuid program is > installed with the expectation that when it runs, certain names will > identify certain files (e.g. /etc/shadow)? But also that certain other > names will identify a file of the invoker's choosing? the new namespace 'n1' though created by the user 'ram', carries the same restrictions to 'ram' . So 'ram' will not be able to mount something else on /bin or /sbin or anyother directory that it does not own, even though its done in its own namespace. Hence I dont see how a attacker would be able fool a malicious setuid program into a genuine setuid program. hope this is the concern you were talking about. right? RP > > >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? > > Essentially. It's a compromise. A user can customize his namespace, but > only within limits that preserve the integrity of the system. > > Technically, we have to admit it's not one namespace today or with > invisible mounts. Because of the way mounts cover up mountpoints, it's > technically possible for two processes to see different files as the same > name, if one opened the directory before a mount and the other after. > "Mounting over" is a curse. > > -- > Bryan Henderson IBM Almaden Research Center > San Jose CA Filesystems