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]

Message-ID: <20240527-raufen-skorpion-fa81805b3273@brauner>
Date: Mon, 27 May 2024 15:17:13 +0200
From: Christian Brauner <brauner@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Aleksa Sarai <cyphar@...har.com>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, 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 02:29:02PM +0200, Christian Brauner wrote:
> On Mon, May 27, 2024 at 04:47:56AM -0700, Christoph Hellwig wrote:
> > On Sun, May 26, 2024 at 12:01:08PM -0700, Aleksa Sarai wrote:
> > > The existing interface already provides a mount ID which is not even
> > > safe without rebooting.
> > 
> > And that seems to be a big part of the problem where the Linux by handle
> > syscall API deviated from all know precedence for no good reason.  NFS
> > file handles which were the start of this do (and have to) encode a
> > persistent file system identifier.  As do the xfs handles (although they
> > do the decoding in the userspace library on Linux for historic reasons),
> > as do the FreeBSD equivalents to these syscalls.
> > 
> > > An alternative would be to return something unique to the filesystem
> > > superblock, but as far as I can tell there is no guarantee that every
> > > Linux filesystem's fsid is sufficiently unique to act as a globally
> > > unique identifier. At least with a 64-bit mount ID and statmount(2),
> > > userspace can decide what information is needed to get sufficiently
> > > unique information about the source filesystem.
> > 
> > Well, every file system that supports export ops already needs a
> > globally unique ID for NFS to work properly.  We might not have good
> > enough interfaces for that, but that shouldn't be too hard.
> 
> I see not inherent problem with exposing the 64 bit mount id through
> name_to_handle_at() as we already to expose the old one anyway.
> 
> But I agree that it is useful if we had the guarantee that file handles
> are unique in the way you describe. As it currently stands that doesn't
> seem to be the case and userspace doesn't seem to have a way of figuring
> out if the handle provided by name_to_handle_at() is indeed unique as
> you describe and can be reliably passed to open_by_handle_at().
> 
> Yes, we should fix it but that's really orthogonal to the mount id. It
> is separately useful and we already do expose it anyway.

Put another way, name_to_handle_at(2) currently states:

   Obtaining a persistent filesystem ID
       The mount IDs in /proc/self/mountinfo can be reused as
       filesystems are unmounted and mounted.  Therefore, the mount ID
       returned by name_to_handle_at()  (in  *mount_id)  should  not  be
       treated  as  a persistent identifier for the corresponding
       mounted filesystem.  However, an application can use the
       information in the mountinfo record that corresponds to the mount
       ID to derive a persistent identifier.

       For example, one can use the device name in the fifth field of
       the mountinfo record to search for the corresponding device UUID
       via the symbolic links in /dev/disks/by-uuid.   (A  more
       comfortable  way  of obtaining the UUID is to use the libblkid(3)
       library.)  That process can then be reversed, using the UUID to
       look up the device name, and then obtaining the corre‐ sponding
       mount point, in order to produce the mount_fd argument used by
       open_by_handle_at().

Returning the 64bit mount id makes this race-free because we now have
statmount():

u64 mnt_id = 0;
name_to_handle_at(AT_FDCWD, "/path/to/file", &handle, &mnt_id, 0);
statmount(mnt_id);

Which gets you the device number which one can use to figure out the
uuid without ever having to open a single file (We could even expose the
UUID of the filesystem through statmount() if we wanted to.).