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

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

[Mario Emmenlauer]

Dear All,

thanks for the awesome Cygwin, its really great!

But since today I met a problem: I mounted a Linux NFSv3 share using
the Windows 10 shipped NFS client. The user and group ID are mapped
via registry settings AnonymousUid and AnonymousGid in the entry
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default

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.

I've read https://cygwin.com/cygwin-ug-net/using-filemodes.html
about the Cygwin file permissions for NFS, and also the NFS account
mapping at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs,
but as far as I can see, they are both unrelated. Google turned up no
useful hits for keywords "cygwin" "test" and "nfs", so I'm a bit at the
end of my wit.

Is this a known issue, and/or are there any workarounds? I'm currently
using `test -e` in place of read or execute checks, but it basically
breaks all my build scrips.

All the best,

     Mario Emmenlauer

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

[Mario Emmenlauer]

On 22.09.20 22:14, Mario Emmenlauer wrote:
> But since today I met a problem: I mounted a Linux NFSv3 share using
> the Windows 10 shipped NFS client. The user and group ID are mapped
> via registry settings AnonymousUid and AnonymousGid in the entry
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
> 
> 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.
> 
> I've read https://cygwin.com/cygwin-ug-net/using-filemodes.html
> about the Cygwin file permissions for NFS, and also the NFS account
> mapping at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs,
> but as far as I can see, they are both unrelated. Google turned up no
> useful hits for keywords "cygwin" "test" and "nfs", so I'm a bit at the
> end of my wit.
> 
> Is this a known issue, and/or are there any workarounds? I'm currently
> using `test -e` in place of read or execute checks, but it basically
> breaks all my build scripts.

Is there something I should do about this issue? I could look into the
source code of `test` on Cygwin if someone can point me to the correct
repository? Or should I just file an issue?

The issue is not a super high priority for me personally, but I guess
its quite a limitation of Cygwin if essential scripting functionality
is misbehaving on NFS.

All the best,

    Mario Emmenlauer

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

[Ken Brown]

On 10/1/2020 6:22 AM, Mario Emmenlauer wrote:
> 
> On 22.09.20 22:14, Mario Emmenlauer wrote:
>> But since today I met a problem: I mounted a Linux NFSv3 share using
>> the Windows 10 shipped NFS client. The user and group ID are mapped
>> via registry settings AnonymousUid and AnonymousGid in the entry
>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
>>
>> 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.
>>
>> I've read https://cygwin.com/cygwin-ug-net/using-filemodes.html
>> about the Cygwin file permissions for NFS, and also the NFS account
>> mapping at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs,
>> but as far as I can see, they are both unrelated. Google turned up no
>> useful hits for keywords "cygwin" "test" and "nfs", so I'm a bit at the
>> end of my wit.
>>
>> Is this a known issue, and/or are there any workarounds? I'm currently
>> using `test -e` in place of read or execute checks, but it basically
>> breaks all my build scripts.
> 
> Is there something I should do about this issue? I could look into the
> source code of `test` on Cygwin if someone can point me to the correct
> repository? Or should I just file an issue?

There is no special source code of 'test' on Cygwin.  Assuming you're working in 
a bash shell, 'test' is a shell builtin, so the source code is part of the 
source code of bash.  (I don't know if other shells have a 'test' builtin.) 
Alternatively, if you're running /usr/bin/test.exe, then it's part of the 
coreutils package.

Either way, looking at that source code is not likely to help, except to see 
what system call it uses to test the access.

> The issue is not a super high priority for me personally, but I guess
> its quite a limitation of Cygwin if essential scripting functionality
> is misbehaving on NFS.

I don't know anything about NFS, but I doubt if this is a general problem with 
NFS on Cygwin.  There's quite a bit of Cygwin code devoted to NFS shares, and 
the question is why this isn't working for yours.

Corinna is probably the only person who knows what questions to ask you to get 
to the bottom of this, and she's currently unavailable.  When she returns, maybe 
she can help.

Ken

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

[Andrey Repin]

Greetings, Mario Emmenlauer!

> thanks for the awesome Cygwin, its really great!

> But since today I met a problem: I mounted a Linux NFSv3 share using
> the Windows 10 shipped NFS client. The user and group ID are mapped
> via registry settings AnonymousUid and AnonymousGid in the entry
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default

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

> I've read https://cygwin.com/cygwin-ug-net/using-filemodes.html
> about the Cygwin file permissions for NFS, and also the NFS account
> mapping at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs,
> but as far as I can see, they are both unrelated. Google turned up no
> useful hits for keywords "cygwin" "test" and "nfs", so I'm a bit at the
> end of my wit.

> Is this a known issue, and/or are there any workarounds? I'm currently
> using `test -e` in place of read or execute checks, but it basically
> breaks all my build scrips.

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.


-- 
With best regards,
Andrey Repin
Tuesday, October 6, 2020 18:42:12

Sorry for my terrible english...

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

[Mario Emmenlauer]

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`?

Cheers,

    Mario Emmenlauer

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

[Corinna Vinschen]

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?


Corinna

Re: 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

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

[Corinna Vinschen]

On Oct 13 21:00, Mario Emmenlauer wrote:
> Hi Corinna, great to have you back :-)

Thanks!

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

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

MSFT NFS is still limited to v3, anyway, on Windows Server, too.

Be it as it is, this is no good reason for your results.  I'm running
AD as name service for the NFS client, but even if you have no name
service for NFS installed, Cygwin fakes the uid/gid to match your own
Windows user (just like on FAT).  So you'd be bound to get more false
positives, rather than false negatives.

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

The MSFT NFS client has two pre-configured entries in the Windows
firewall called "Client for NFS (TCP-Out)" and "Client for NFS
(UDP-Out)".  These should be activated, nothing more should be required
(unless using a name service, AD or RFC 2307, but that's a different
story).

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

Wrong uid/gid could wreck havoc, though.  Maybe there is a bug in terms
of using NFS without name service.

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


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: 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

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

[Corinna Vinschen]

On Oct 14 11:06, Mario Emmenlauer wrote:
> On 14.10.20 10:28, Corinna Vinschen wrote:
> > 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

This is entirely unrelated.  We're talking about Cygwin stat(2),
not msvcrt.dll _stat().  Different source, different call.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

[Mario Emmenlauer]

On 14.10.20 13:50, Corinna Vinschen wrote:
> On Oct 14 11:06, Mario Emmenlauer wrote:
>> On 14.10.20 10:28, Corinna Vinschen wrote:
>>> 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
> 
> This is entirely unrelated.  We're talking about Cygwin stat(2),
> not msvcrt.dll _stat().  Different source, different call.

Yes, but Cygwin stat is implemented based on the Win32 posix layer too,
or not? At least I got this impression from browsing the sources -
albeit admittedly there are far too many indirections and ifdefs for
me to really know what's going on... :-) :-)

All the best,

    Mario

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

[Corinna Vinschen]

On Oct 14 16:57, Mario Emmenlauer wrote:
> On 14.10.20 13:50, Corinna Vinschen wrote:
> > On Oct 14 11:06, Mario Emmenlauer wrote:
> >> On 14.10.20 10:28, Corinna Vinschen wrote:
> >>> 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
> > 
> > This is entirely unrelated.  We're talking about Cygwin stat(2),
> > not msvcrt.dll _stat().  Different source, different call.
> 
> Yes, but Cygwin stat is implemented based on the Win32 posix layer too,
> or not?

No, Cygwin is using the NT layer functions to access filesystems.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer