There were no cross-junction operations in this case. It is possible that exportid has been reassigned in the configuration, but the FSID is unique.
Regards. Krishna Harathi On Mon, Dec 14, 2015 at 6:08 AM, Daniel Gryniewicz <[email protected]> wrote: > Is it possible that a junction was crossed in the operation? That > would, of course, change the export the operation occurs on... > > Dan > > On Fri, Dec 11, 2015 at 7:57 PM, Krishna Harathi <[email protected]> > wrote: > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > > >
------------------------------------------------------------------------------
_______________________________________________ Nfs-ganesha-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
