From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: NFS4 crack Date: Mon, 19 Sep 2005 09:35:28 -0400 Message-ID: <20050919133528.GA20732@fieldses.org> References: <20050918102100.GA23463@lst.de> <20050918143615.GA3428@fieldses.org> <20050919103547.GA8998@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: akpm@osdl.org, neilb@cse.unsw.edu.au, andros@citi.umich.edu, linux-fsdevel@vger.kernel.org Return-path: Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214]:11446 "EHLO pickle.fieldses.org") by vger.kernel.org with ESMTP id S932384AbVISNfh (ORCPT ); Mon, 19 Sep 2005 09:35:37 -0400 To: Christoph Hellwig Content-Disposition: inline In-Reply-To: <20050919103547.GA8998@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Sep 19, 2005 at 12:35:47PM +0200, Christoph Hellwig wrote: > Namespaces issues above was meant as kernel can't assume namespace at > all, not even thinking about multiple namespaces which makes it even > more wrong. Who sais I allow the kernel to mess with > /var/lib/nfs/v4recover? It's run-time configurable if you don't like the default. > Who tells any userspace process is even in the same namespace as the > nfs threads to create the directories? No userspace process is likely to care, except maybe for debugging purposes. This isn't a userspace<->kernel interface, it's just a way to store some information on disk so nfsd can find it again on next boot. > Kernel assuming any namespace is wrong and we don't do it anywhere. Well, nfsd does have some assumptions--mountd, exportfs, and nfsd all have to be in the same namespace, for example. (Or at least namespaces that are identical on exported paths.) > > > The fs handling in fs/nfs/nfs4recovery.c is rather broken in addition. > > > > For example? > > - opens a directory O_RDWR which open_namei wouldn't even allow > - tries to build dentry list from vfs_readdir callback, leading to > deadlocks on filesystems that take the same lock from readdir > and lookup > - resets fsuid/fsgids without checks, synchronization or callouts > into subsystems that care (security, keys, ptrace) > - looks up /var/lib/nfs/v4recovery without ensuring it's a directory > > and probably a few more if one tried to look at it for more than five > minutes. Are you sure about readdir? It looks to me like nfsd has done lookups there for some time--see, e.g., fs/nfsd/nfs3xdr.c:compose_entry_fh(). But I'll read through it again and check the other stuff you mention, thanks. --b.