linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] open_by_handle() vs. EA inodes
Date: Fri, 29 Jun 2018 21:15:48 +0100	[thread overview]
Message-ID: <20180629201548.GR30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180629195732.GQ30522@ZenIV.linux.org.uk>

On Fri, Jun 29, 2018 at 08:57:32PM +0100, Al Viro wrote:
> 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...

Note, BTW, that journal inode will be rejected by
        if (ino < EXT4_FIRST_INO(sb) && ino != EXT4_ROOT_INO)
                return ERR_PTR(-EFSCORRUPTED);
in ext4_iget_normal(); EA inodes won't be, since their numbers
are in the normal range.  And looking at the commit that has
introduced ext4_iget_normal(), I'd say that EA inodes fit the
description in
commit f4bb2981024fc91b23b4d09a8817c415396dbabb
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Oct 5 22:56:00 2014 -0400

    ext4: add ext4_iget_normal() which is to be used for dir tree lookups

    If there is a corrupted file system which has directory entries that
    point at reserved, metadata inodes, prohibit them from being used by
    treating them the same way we treat Boot Loader inodes --- that is,
    mark them to be bad inodes.  This prohibits them from being opened,
    deleted, or modified via chmod, chown, utimes, etc.
    
    In particular, this prevents a corrupted file system which has a
    directory entry which points at the journal inode from being deleted
    and its blocks released, after which point Much Hilarity Ensues.

anyway.  IOW, it might be better to have that check done not in
ext4_nfs_get_inode() but in ext4_iget_normal(), as in
struct inode *ext4_iget_normal(struct super_block *sb, unsigned long ino)
{
	struct inode *res;
        if (ino < EXT4_FIRST_INO(sb) && ino != EXT4_ROOT_INO)
                return ERR_PTR(-EFSCORRUPTED);
	res = ext4_iget(sb, ino);
	if (IS_ERR(res) || likely(!(EXT4_I(res)->i_flags & EXT4_EA_INODE_FL)))
		return res;
	iput(res);
	return ERR_PTR(-EFSCORRUPTED);
}

Objections?

  reply	other threads:[~2018-06-29 20:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 18:19 [RFC] open_by_handle() vs. EA inodes Al Viro
2018-06-29 19:38 ` Trond Myklebust
2018-06-29 19:57   ` Al Viro
2018-06-29 20:15     ` Al Viro [this message]
2018-07-03 16:46       ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180629201548.GR30522@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).