Re: Question: When NFS client check dir's permission, it does not check the cache data

[Wei Yongjun <yjwei@cn.fujitsu.com>]

[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]

Sorry to trouble again, it is this a real problem of NFS?
>>> I mean that read a dir, such as lookup a dir.
>>> If I reply a getattr as that dir has no lookup permission, and then do a
>>> "cat /nfsroot/dir/file" at client, client will not send lookup procedure to
>>> server, because client used the cache data of the dir. It like this:
>>> client server
>>> #ls /nfsroot
>>> readdirplus ------------------>
>>> <------------- readdirplus reply
>>> (attribute of dir has no lookup permission)
>>> # cat /nfsroot/dir/file
>>> (send nothing, used cache data)
>>> -------no package is send-------
>>>
>>> If no cache data exists, it would like this:
>>> client server
>>> #ls /nfsroot
>>> readdirplus ------------------>
>>> <------------- readdirplus reply
>>> (attribute of dir has no lookup permission)
>>> # cat /nfsroot/dir/file
>>> access(dir) ------------------->
>>> <------------- access reply(dir)
>>> (has no lookup permission)
>>>
>>> And if has permission to lookup dir, it would like this:
>>> client server
>>> #ls /nfsroot
>>> readdirplus ------------------>
>>> <------------- readdirplus reply
>>> (attribute of dir has no lookup permission)
>>> # cat /nfsroot/dir/file
>>> access(dir) -------------------> (*1)
>>> <------------- access reply(dir)
>>> lookup(file) ------------------->
>>> <------------- lookup reply(file)
>>> read(file) ------------------->
>>> <------------- read reply(file)
>>>
>>> While you optimize all write operations to omit access procedure, can
>>> this access (*1) be omitted? Then lookup(file) will return NOPERM.
>>>     
>>>       
>> So what if I change the permissions on the directory? What should the
>> rules be for caching these attributes?
>>
>> ...and you still haven't replied to my question about what
>> application/workload actually _cares_ about optimising for this
>> particular case.
>>   
>>     
> No application cares this ^_^, just for test.
> I test the read op of dir, it maybe has tiny bug in it. As you said, if
> I chmod of dir, client will be a little later to know this.
> Test step ad following:
>
> [root@REHL ~]# mount -t nfs 192.168.0.19:/nfsroot /mnt
> [root@REHL ~]# ll /mnt
> total 4
> dr-xr-xr-x 2 root root 4096 Jun 23  2007 dir
> [root@REHL ~]# ll /mnt/dir
> total 4
> -rw-r--r-- 1 root root 5 Jun 24  2007 file
> [root@REHL ~]# su weiyj
> [weiyj@REHL root]$ ll /mnt
> total 4
> dr-xr-xr-x 2 root root 4096 Jun 23  2007 dir
> [weiyj@REHL root]$ ll /mnt/dir
> total 4
> -rw-r--r-- 1 root root 5 Jun 24  2007 file
> [weiyj@REHL root]$ cat /mnt/dir/file
> test
> [weiyj@REHL root]$ ssh 192.168.0.19 -l root chmod a-x /nfsroot/dir
> [weiyj@REHL root]$ cat /mnt/dir/file
> test
> [weiyj@REHL root]$ cat /mnt/dir/file
> test
> [weiyj@REHL root]$ ll /mnt/dir
> total 0
> ?--------- ? ? ? ?            ? /mnt/dir/file
> [weiyj@REHL root]$ ll /mnt
> total 4
> dr--r--r-- 2 root root 4096 Jun 23  2007 dir
> [weiyj@REHL root]$ cat /mnt/dir/file
> cat: /mnt/dir/file: Permission denied
>   


-- 

A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: yjwei@cn.fujitsu.com 
--------------------------------------------------
Wei Yongjun
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630523-858
COINS: 79955-858
FAX: +86+25-83317685
MAIL: yjwei@cn.fujitsu.com
--------------------------------------------------



[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs