Re: [PATCH] NFSD: nfsctl: remove read permission of filehandle

[Jeff Layton <jlayton@kernel.org>]

On Wed, 2024-03-20 at 15:49 +0000, Hanxiao Chen (Fujitsu) wrote:
> 
> > -----邮件原件-----
> > 发件人: Jeff Layton <jlayton@kernel.org>
> > 发送时间: 2024年3月19日 21:09
> > 收件人: Chen, Hanxiaochenhx.fnst@fujitsu.com>; Chuck Lever
> > <chuck.lever@oracle.com>; Neil Brown <neilb@suse.de>; Olga Kornievskaia
> > <kolga@netapp.com>; Dai Ngo <Dai.Ngo@oracle.com>; Tom Talpey
> > <tom@talpey.com>
> > 抄送: linux-nfs@vger.kernel.org
> > 主题: Re: [PATCH] NFSD: nfsctl: remove read permission of filehandle
> > 
> > On Tue, 2024-03-19 at 18:47 +0800, Chen Hanxiao wrote:
> > > As write_filehandle can't accept zero-bytes writting,
> > > remove read permission of /proc/fs/nfsd/filehandle
> > > 
> > > Signed-off-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
> ...
> > 
> > 
> > I don't think we can do this. mountd does this to get the rootfh for an
> > exported fs and it'll probably start failing if it can't open that file
> > for read:
> > 
> >     f = open("/proc/fs/nfsd/filehandle", O_RDWR);
> > 
> > That write_filehandle interface sure is weird though. Could we get rid
> > of it by teaching cache_get_filehandle how to use name_to_handle_at
> > instead? That would be a lot cleaner and would get rid of yet another
> > dependency on /proc/fs/nfsd.
> 
> name_to_handle_at return struct file_handle
> cache_get_filehandle return hexed struct knfsd_fh
> 
> Could you please give some hints on how to convert from file_handle. f_handle to knfsd_fh.fh_raw?
> 

I started looking at this yesterday. knfsd_fh is mostly constructed in
fh_compose. The exportfs_encode_fh call is in _fh_update. If we look at
the comments over knfsd_fh, it explains pretty well what we need to fill
out:

fh_version : should always be 1
fh_auth_type: always 0
fh_fsid_type: this is the tricky part (see below)
fh_fileid_type: returned by name_to_handle_at
fh_fsid: fsid concatenated with the fileid for the inode

name_to_handle_at should be able to fill out the fileid portion of the
knfsd_fh. The harder part is: how do we get the fh_fsid_type and its
content?

The types are shown here:

* The fsid_type identifies how the filesystem (or export point) is
 *    encoded.
 *  Current values:
 *     0  - 4 byte device id (ms-2-bytes major, ls-2-bytes minor), 4byte inode number
 *        NOTE: we cannot use the kdev_t device id value, because kdev_t.h
 *              says we mustn't.  We must break it up and reassemble.
 *     1  - 4 byte user specified identifier
 *     2  - 4 byte major, 4 byte minor, 4 byte inode number - DEPRECATED
 *     3  - 4 byte device id, encoded for user-space, 4 byte inode number
 *     4  - 4 byte inode number and 4 byte uuid
 *     5  - 8 byte uuid
 *     6  - 16 byte uuid
 *     7  - 8 byte inode number and 16 byte uuid

The kernel decides this in set_version_and_fsid_type, so I suppose we
could try to replicate that logic in userland.

There is the problem though of what to do about exports with the fsid=
option set. That's tougher to determine from userland, but maybe we can
somehow get that from the export record?

That's about as far as I got with it yesterday...
-- 
Jeff Layton <jlayton@kernel.org>