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

[Mario Emmenlauer]

Hi Corinna, great to have you back :-)

On 13.10.20 20:36, Corinna Vinschen wrote:
> On Oct  6 18:10, Mario Emmenlauer wrote:
>>
>> Dear Andrey,
>>
>> On 06.10.20 17:46, Andrey Repin wrote:
>>> Greetings, Mario Emmenlauer!
>>>
>>>> thanks for the awesome Cygwin, its really great!
>>>
>>>> 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.
>>>
>>> This is a known issue. For years known.
>>> test only guess -r/-w/-x results based on permissions as it sees them.
>>> But it do not actually try to read/write/execute the subject, which, as you
>>> can imagine, may lead to all sorts of false positives/negatives on filesystems
>>> with less than trivial access control setups.
>>> In other words, don't test for rwx if you can avoid it. The results MAY be
>>> wrong.
>>
>>
>> Ok, this explains a lot, and I almost guessed as much! But can I ask,
>> do you happen to know why `ls -l` shows the "correct" permissions
>> including 'r' and 'x'? It seems `ls` has some magic that `test` is
>> lacking? And I can not imagine that `ls` would try to open every
>> file, or does it?.
>>
>> So could this "magic" be ported from `ls` to `test`?
> 
> 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.

The only "weak link" in my setup is the NFS mount. I'm no expert
in exporting NFS, nor in mounting NFS from Windows. Maybe something
is fishy there, albeit I did not use any special parameters or
quirks (again, to the best of my knowledge). What I can say is that
I'm limited to NFS v3 since its not a Server-Edition Windows. Also,
I tried my best to open all NFS ports in the firewall but possibly
I'm not running one of the many extended NFS services like lockd
or something. I checked that most are installed, running and use a
static port, but its hard to be sure, since NFS seems to support
quite many "extras".

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...

All the best,

     Mario