On Wed, 2024-03-20 at 15:49 +0000, Hanxiao Chen (Fujitsu) wrote:
>
> > -----邮件原件-----
> > 发件人: Jeff Layton <jlayton@xxxxxxxxxx>
> > 发送时间: 2024年3月19日 21:09
> > 收件人: Chen, Hanxiaochenhx.fnst@xxxxxxxxxxx>; Chuck Lever
> > <chuck.lever@xxxxxxxxxx>; Neil Brown <neilb@xxxxxxx>; Olga Kornievskaia
> > <kolga@xxxxxxxxxx>; Dai Ngo <Dai.Ngo@xxxxxxxxxx>; Tom Talpey
> > <tom@xxxxxxxxxx>
> > 抄送: linux-nfs@xxxxxxxxxxxxxxx
> > 主题: 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@xxxxxxxxxxx>
> ...
> >
> >
> > 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@xxxxxxxxxx>
