[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Zl6kjsiGl0pm-p-o@infradead.org>
Date: Mon, 3 Jun 2024 22:22:22 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Aleksa Sarai <cyphar@...har.com>
Cc: Miklos Szeredi <miklos@...redi.hu>,
Christoph Hellwig <hch@...radead.org>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
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 Sat, Jun 01, 2024 at 01:12:31AM -0700, Aleksa Sarai wrote:
> Not to mention that providing a mount fd is what allows for extensions
> like Christian's proposed method of allowing restricted forms of
> open_by_handle_at() to be used by unprivileged users.
As mentioned there I find the concept of an unprivileged
open_by_handle_at extremely questionable as it trivially gives access to
any inode on the file systems.
> If file handles really are going to end up being the "correct" mechanism
> of referencing inodes by userspace,
They aren't.
> then future API designs really need
> to stop assuming that the user is capable(CAP_DAC_READ_SEARCH).
There is no way to support open by handle for unprivileged users. The
concept of an inode number based file handle simply does not work for
that at all.
Powered by blists - more mailing lists