test -r or -x always return false on an NFS mount?

[Mario Emmenlauer]

On 14.10.20 10:28, Corinna Vinschen wrote:
> On Oct 13 21:00, Mario Emmenlauer wrote:
>> On 13.10.20 20:36, Corinna Vinschen wrote:
>>>>>> Everything seems to work quite well, and in `ls -la` I can see the
>>>>>> file permissions and user and group entries. But when using `test`
>>>>>> to check for read (`test -r`) or execute permissions (`test -x`), it
>>>>>> always returns false, even for readable files. `ls` on the other hand
>>>>>> shows the permissions correctly, and `cat`ing the files works without
>>>>>> problems.
>>>
>>> There's something fishy in your environment.  NFS permissions from NFS
>>> shares mounted via Microsoft's NFSv3 are read using some internal
>>> function I got hinted at by the MSFT NFS guys at one point.  This
>>> information is then exported as mode bits by Cygwin's stat(2) and used
>>> accordingly by Cygwin's access(2).
>>>
>>> Having said that, there's *no* magic at all in the user space
>>> applications other than using Cygwin's stat(2) and access(2) functions.
>>>
>>> Consequentially, using Cygwin's ls(1) or test(1) from coreutils, the
>>> results are the expected ones in both cases; just tried it myself, just
>>> to be sure.
>>>
>>> So, what's fishy?  I don't know, but maybe you're using a non-Cygwin
>>> test(1) accidentally?
>>
>> I see your point, but to the best of my knowledge there is nothing
>> fishy. Its a freshly set up computer with an official Windows 10 x64
>> from Microsoft directly. I've installed all latest updates including
>> the 2004 update. Cygwin was also just installed a few months ago.
>>
>> I did use a script to install Cygwin via its installer in an automated
>> fashion, but I've run the normal, graphical installer a few times since
>> then to make sure everything is nice and clean.
>>
>> Calling "which test" shows "/usr/bin/test", but since I use only
>> bash in all my scripts, I guess it anyways defaults to the builtin.
> 
> Please check and try again with the stand-alone test(1), too.

Sorry, I should have mentioned this: it gives the same result.


>> Is there anything I can do to isolate this further? Its a quite
>> curious case and I'm basically at the end of my wit...
> 
> Actually, not really.  It's weird in fact, given ls(1) shows the
> desired result.  That would point to a bug in access(2), but there's
> no special code in access(2) for NFS.  For filesystems not supporting
> ACLs (FAT, NFS, etc), it calls stat(2) and checks the st_mode bits
> against the requested access(2) mode based on the uid/gid of the
> caller, simple as that.

Hmm, now that you mention it, I just coincidentally found an issue
with the `_stat` call in Microsoft Windows 2004 update. In the Apache
thrift project I found that `_stat` stopped working on domain socket
files on Windows. This sounds not directly identical, but could be
well related. I did not try `_stat` in other situations, but something
must have changed there very recently.

The issue is reported upstream, but sadly for the wrong product
(Visual Studio), so nobody is following up this report anymore:
https://developercommunity.visualstudio.com/content/problem/1180994/-stat-fails-on-existing-domain-socket-file-when-bu.html
(Scroll to the bottom to see the full report).


> Please call ls(1) and test(1) -r (not the bash builtin) on a file
> exposing the behaviour under strace like this:
> 
>    $ strace -o ls.trace /bin/ls -l <file>
>    $ strace -o test.trace /bin/test -r <file>
> 
> and send the trace files here, together with the output of the above
> ls(1) call and the output of id(1).

I will to that! Thanks for your help and interest!!

All the best,

     Mario Emmenlauer