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