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: <30137c868039a3ae17f4ae74d07383099bfa4db8.camel@hammerspace.com>
Date: Sun, 26 May 2024 22:32:39 +0000
From: Trond Myklebust <trondmy@...merspace.com>
To: "cyphar@...har.com" <cyphar@...har.com>, "hch@...radead.org"
	<hch@...radead.org>
CC: "jack@...e.cz" <jack@...e.cz>, "brauner@...nel.org" <brauner@...nel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"chuck.lever@...cle.com" <chuck.lever@...cle.com>, "alex.aring@...il.com"
	<alex.aring@...il.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "viro@...iv.linux.org.uk"
	<viro@...iv.linux.org.uk>, "jlayton@...nel.org" <jlayton@...nel.org>,
	"amir73il@...il.com" <amir73il@...il.com>, "linux-nfs@...r.kernel.org"
	<linux-nfs@...r.kernel.org>
Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to
 name_to_handle_at(2)

On Sun, 2024-05-26 at 02:25 -0700, Christoph Hellwig wrote:
> On Thu, May 23, 2024 at 01:57:32PM -0700, Aleksa Sarai wrote:
> > Now that we provide a unique 64-bit mount ID interface in statx, we
> > can
> > now provide a race-free way for name_to_handle_at(2) to provide a
> > file
> > handle and corresponding mount without needing to worry about
> > racing
> > with /proc/mountinfo parsing.
> 
> file handles are not tied to mounts, they are tied to super_blocks,
> and they can survive reboots or (less relevant) remounts.  This thus
> seems like a very confusing if not wrong interfaces.

I assume the reason is to give the caller a race free way to figure out
which submount the path resolves to. The problem is that nothing stops
another process from calling umount() before you're done parsing
/proc/mountinfo and have resolved the mount id.

If we're looking to change the API, then perhaps returning a file
descriptor might be a better alternative?
Most userland NFS servers are in any case going to follow up obtaining
the filehandle with a stat() or even a full blown open() in order to
get file attributes, set up file state, etc. By returning an open file
descriptor to the resolved file (even if it is only an O_PATH
descriptor) we could accelerate those operations in addition to solving
the umount() race.

Alternatively, just remove the path argument altogether, and require
the descriptor argument to be an O_PATH or regular open file descriptor
that resolves to the file we want to get a filehandle for. However this
would require a userland NFS server to generally do a
open_by_handle_at() to resolve the parent directory handle, then do an
openat(O_PATH) to get the file to look up, before being able to call
the name_to_handle_at() replacement.
i.e. there would be 1 extra syscall.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com