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: Mon, 27 May 2024 09:24:02 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Jan Kara <jack@...e.cz>
Cc: Christoph Hellwig <hch@...radead.org>, Aleksa Sarai <cyphar@...har.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>,
	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 Mon, May 27, 2024 at 03:34:30PM +0200, Jan Kara wrote:
> So I was wondering how this is actually working in practice. Checking the
> code, NFS server is (based on configuration in /etc/exports) either using
> device number as the filesystem identifier or fsid / uuid as specified in
> /etc/exports.

Yes, it's a rather suboptimal implementation.

> So returning the 64-bit mount ID from name_to_handle_at() weasels out of
> these "how to identify arbitrary superblock" problems by giving userspace a
> reasonably reliable way to generate this superblock identifier itself. I'm
> fully open to less errorprone API for this but at this point I don't see it
> so changing the mount ID returned from name_to_handle_at() to 64-bit unique
> one seems like a sane practical choice to me...

Well, how about we fix the thing for real:

 - allow file systems to provide a uniqueu identifier of at least
   uuid size (16 bytes) in the superblock or through an export operation
 - for non-persistent file systems allow to generate one at boot time
   using the normal uuid generation helpers
 - add a new flag to name_to_handle_at/open_by_handle_at to include it
   in the file handle, and thus make the file handle work more like
   the normal file handle
 - add code to nfsd to directly make use of this

This would solve all the problems in this proposal as well as all the
obvious ones it doesn't solve.