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 <khara...@exablox.com> 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
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
