From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:44172 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935467AbeF2T5e (ORCPT ); Fri, 29 Jun 2018 15:57:34 -0400 Date: Fri, 29 Jun 2018 20:57:32 +0100 From: Al Viro To: Trond Myklebust Cc: "linux-ext4@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" Subject: Re: [RFC] open_by_handle() vs. EA inodes Message-ID: <20180629195732.GQ30522@ZenIV.linux.org.uk> References: <20180629181900.GP30522@ZenIV.linux.org.uk> <701debe87eff185064f3cc31f9a9b425cdf8fe61.camel@hammerspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <701debe87eff185064f3cc31f9a9b425cdf8fe61.camel@hammerspace.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Jun 29, 2018 at 07:38:30PM +0000, Trond Myklebust wrote: > On Fri, 2018-06-29 at 19:19 +0100, Al Viro wrote: > > On ea_inode-enabled ext4 open_by_handle() (as well as knfsd, > > etc.) > > can get to EA inodes as long as it knows their inumbers - just pass > > it > > an fhandle with zeroed version bytes and the right inumber in it. > > > > AFAICS, it's Not Nice(tm), especially since you can write to > > those, > > whether they are shared or not. > > > > Should we make ext4_nfs_get_inode() check for EXT4_EA_INODE_FL > > and fail if it's set? > > handle_to_path() requires CAP_DAC_READ_SEARCH capabilities. Isn't that > sufficiently restrictive for open_by_handle()? > > Concerning knfsd, people can in theory enable subtree checking to > enforce checking whether or not you are in an exported subtree. In > practice that breaks rename, so people are strongly encouraged to > disable subtree checking, and only to export complete filesystems. Umm... Do we ever want those accessed via fhandles, capabilities or no capabilities? IOW, is there any reason for ext4 ->fh_to_dentry() to give access to such inodes? Those are implementation internals, same as e.g. journal inode...