linux-kernel - Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle

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: Wed, 29 May 2024 09:40:01 +0200
From: Christian Brauner <brauner@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Jan Kara <jack@...e.cz>, Aleksa Sarai <cyphar@...har.com>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Chuck Lever <chuck.lever@...cle.com>, 
	Jeff Layton <jlayton@...nel.org>, Amir Goldstein <amir73il@...il.com>, 
	Alexander Aring <alex.aring@...il.com>, linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to
 name_to_handle_at(2)

On Tue, May 28, 2024 at 06:22:23AM -0700, Christoph Hellwig wrote:
> On Tue, May 28, 2024 at 02:04:16PM +0200, Christian Brauner wrote:
> > Can you please explain how opening an fd based on a handle returned from
> > name_to_handle_at() and not using a mount file descriptor for
> > open_by_handle_at() would work?
> 
> Same as NFS file handles:
> 
> name_to_handle_at returns a handle that includes a file system
> identifier.
> 
> open_by_handle_at looks up the superblock based on that identifier.
> 
> For the identifier I could imagin three choices:
> 
>  1) use the fsid as returned in statfs and returned by fsnotify.
>     The downside is that it is "only" 64-bit.  The upside is that
>     we have a lot of plumbing for it
>  2) fixed 128-bit identifier to provide more entropy
>  3) a variable length identifier, which is more similar to NFS,
>     but also a lot more complicated
> 
> We'd need a global lookup structure to find the sb by id.  The simplest
> one would be a simple linear loop over super_blocks which isn't terribly
> efficient, but probably better than whatever userspace is doing to
> find a mount fd right now.
> 
> Let me cook up a simple prototype for 1) as it shouldn't be more than
> a few hundred lines of code.

Yeah, that's exactly what I figured and no that's not something we
should do.

Not just can have a really large number of superblocks if you have mount
namespaces and large container workloads that interface also needs to be
highly privileged.

Plus, you do have filesystems like btrfs that can be mounted multiple
times with the same uuid.

And in general users will still need to be able to legitimately use a
mount fd and not care about the handle type used with it.