From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call Date: Wed, 20 Apr 2005 23:13:58 +0100 Message-ID: <20050420221358.GC21150@mail.shareable.org> References: <20050419222324.GM13052@parcelfarce.linux.theplanet.co.uk> <20050420033304.GO13052@parcelfarce.linux.theplanet.co.uk> <20050420094558.GB10167@mail.shareable.org> <20050420124829.GB23518@vagabond> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , Eric Van Hensbergen , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:1189 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S261823AbVDTWOM (ORCPT ); Wed, 20 Apr 2005 18:14:12 -0400 To: Jan Hudec Content-Disposition: inline In-Reply-To: <20050420124829.GB23518@vagabond> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jan Hudec wrote: > > For FUSE, what's needed is that a user can mount something, and the > > mounted fs is visible only to that user, but it's visible to _all_ of > > the user's processes. > > Including root's su to that user... > Keeping information in a process group is the *only* way to actually > lock out root. If root is _intending_ to view the user's data, it will succeed. Keeping them in a process group won't prevent that: root can look at the data accessible by any process (via ptrace or /dev/mem). The problem most clearly illustrating the need for private user data is sshfs, or anything which mounts over ssl/tls. > That is, except some kind of keyring in kernel. For secure user data, as in sshfs, that's the only real solution: a keyring in kernel which cannot be accessed simply by calling su, and which must be accessed to gain access to the mounted directory. Which is no different from securing user data when scp+ssh-agent is used. -- Jamie