Looks like some possible validation is missing in while checking a
filehandle got from a client.
Ganesha is wrongly determining the check_acess just based on the exportid
encoded in the
filehandle without validating the rest of the filehandle as seen below.
11/12/2015 T12:46:48.502444-0800 : nfs-ganesha-24381[work-4] 391
> :nfs3_Is_Fh_Invalid :FH :F_DBG :NFS3 Handle
> (28:0x41000c001644f7fffd0419f6cd048100000000010000000000000000)
> 11/12/2015 T12:46:48.502450-0800 : nfs-ganesha-24381[work-4] 287
> :get_gsh_export :HT CACHE :DEBUG :export_mgr cache hit slot 12
> 11/12/2015 T12:46:48.502454-0800 : nfs-ganesha-24381[work-4] 945
> :nfs_rpc_execute :DISP :M_DBG :DISP: MID DEBUG: Found export entry for
> path=/exports/nfs32 as exportid=12
> 11/12/2015 T12:46:48.502465-0800 : nfs-ganesha-24381[work-4] 2211
> :export_check_access :EXPORT :M_DBG :Check for address 192.168.201.78 for
> export id 12 fullpath /exports/nfs32
> 11/12/2015 T12:46:48.502481-0800 : nfs-ganesha-24381[work-4] 2308
> :export_check_access :EXPORT :M_DBG :Final options (all_squash , RWrw,
> 3--, UDP, TCP, ----, No Manage_Gids, -- Deleg,
11/12/2015 T12:46:48.502484-0800 : nfs-ganesha-24381[work-4] 333
> :get_req_creds :DISP :M_DBG :DISP: MID DEBUG: AUTH_SYS creds squashed to
> uid=4294967294, gid=4294967294
Above, the filehandle has led to exportid 12 /exports/nfs32. Further down,
the actual file operation
(create) is done on a different export as seen below.
11/12/2015 T12:46:48.502513-0800 : nfs-ganesha-24381[work-4] 391
> :nfs3_Is_Fh_Invalid :FH :F_DBG :NFS3 Handle
> (28:0x41000c001644f7fffd0419f6cd048100000000010000000000000000)
> 11/12/2015 T12:46:48.502521-0800 : nfs-ganesha-24381[work-4] 345
> :vfs_extract_fsid :FSAL :M_DBG :Handle len 22 0x44:
> fsid=0x0000000004fdfff7.0x0000000004cdf619, type 0x81, opaque:
> (12:0x000000000100000000000000)
> 11/12/2015 T12:46:48.502530-0800 : nfs-ganesha-24381[work-4] 1694
> :vfs_check_handle :FSAL :DEBUG :Found filesystem /exports/nfs14 for handle
> for FSAL VFS
gdb is showing /exports/nfs32 is at exportid 12 but the intended
/exports/nfs14 is at exportid 15.
(gdb) print *get_gsh_export_by_path_locked("/exports/nfs32", 0)show
> last_update = 320381826978325, state = EXPORT_READY, options = 2,
> options_set = 1, expire_time_attr = 60, export_id = 12}
> (gdb) print *get_gsh_export_by_path_locked("/exports/nfs14", 0)
> last_update = 244761665623320, state = EXPORT_READY, options = 2,
> options_set = 1, expire_time_attr = 60, export_id = 15}
Assuming that the exportid has changed for the exports (still investigating
that issue), question to you all is it possible to validate the handle by
making sure that the correct FSID is there in the slot as shown by
exportid?
We are using Ganesha 2.1.0 NFSv3 only, but I see that 2.3.0 code has not
changed much in this
specific area.
Regards.
Krishna Harathi
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
