From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josef Sipek Subject: Re: [RFC] Privilege escalation in filesystems Date: Wed, 9 Aug 2006 18:37:55 -0400 Message-ID: <20060809223755.GD1882@filer.fsl.cs.sunysb.edu> References: <20060809215200.GB1882@filer.fsl.cs.sunysb.edu> <1155161852.15624.50.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Al Viro , ezk@cs.sunysb.edu, dquigley@ic.sunysb.edu, dpquigl@tycho.nsa.gov Return-path: To: Trond Myklebust Content-Disposition: inline In-Reply-To: <1155161852.15624.50.camel@localhost> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Aug 09, 2006 at 06:17:32PM -0400, Trond Myklebust wrote: > On Wed, 2006-08-09 at 17:52 -0400, Josef Sipek wrote: ... > > (fs/nfs/nfs4recover.c:nfs4_save_user) > > current->fsuid = 0; > > current->fsgid = 0; > > This sort of thing can be defeated by selinux. I was affraid of that. > The right way to perform privileged operations is normally to give the > task to a kernel thread that has the required privileges (for instance a > work_queue like keventd). This makes sense. So, I suppose it would make sense to have a per-mount or per-superblock pdflush-like thread that gets instantiated on mount. > Ugh. Having the kernel interpret magic directory entries is just evil. > Having the kernel magically create and remove said entries on behalf of > the user ought to be punishable by death. I'd like to hear about anything that is as portable, but not as "evil" :) > Why can't you use something like an xattr to label opaqueness (or > visibility!) instead? The goal is to have as few restrictions as possible - not every file system supports xattr. Josef "Jeff" Sipek. -- Bus Error: passangers dumped.