From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: NFS4 crack Date: Mon, 19 Sep 2005 12:35:47 +0200 Message-ID: <20050919103547.GA8998@lst.de> References: <20050918102100.GA23463@lst.de> <20050918143615.GA3428@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , akpm@osdl.org, neilb@cse.unsw.edu.au, andros@citi.umich.edu, linux-fsdevel@vger.kernel.org Return-path: Received: from verein.lst.de ([213.95.11.210]:40361 "EHLO mail.lst.de") by vger.kernel.org with ESMTP id S932406AbVISKhN (ORCPT ); Mon, 19 Sep 2005 06:37:13 -0400 To: "J. Bruce Fields" Content-Disposition: inline In-Reply-To: <20050918143615.GA3428@fieldses.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, Sep 18, 2005 at 10:36:15AM -0400, J. Bruce Fields wrote: > On Sun, Sep 18, 2005 at 12:21:00PM +0200, Christoph Hellwig wrote: > > I've recently turned on NFS4 server support accidentally, just to get > > error messages like: > > > > "NFSD: recovery directory /var/lib/nfs/v4recovery doesn't exist" > > > > To my horror I found out that this comes from kernel code, which messes > > with a hardcoded directory, completelyu ingoring any namespace or other > > uses issues. > > As long as all nfsd threads are in the same namespace, I don't see any > namespace issues. What am I missing? 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? Who tells any userspace process is even in the same namespace as the nfs threads to create the directories? Kernel assuming any namespace is wrong and we don't do it anywhere. > > > 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. This is code that could be a third of the size if written in userpsace and actually had a chance to be correct there, nevermind the policy violations. Please remove the code and never ever try to sneak in something like that again. Thanks.