lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 29 Jun 2018 20:57:32 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Trond Myklebust <trondmy@...merspace.com>
Cc:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC] open_by_handle() vs. EA inodes

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...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ