* test -r or -x always return false on an NFS mount? @ 2020-09-22 20:14 Mario Emmenlauer 2020-10-01 10:22 ` Mario Emmenlauer 2020-10-06 15:46 ` Andrey Repin 0 siblings, 2 replies; 12+ messages in thread From: Mario Emmenlauer @ 2020-09-22 20:14 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-09-22 20:14 test -r or -x always return false on an NFS mount? Mario Emmenlauer @ 2020-10-01 10:22 ` Mario Emmenlauer 2020-10-06 1:41 ` Ken Brown 2020-10-06 15:46 ` Andrey Repin 1 sibling, 1 reply; 12+ messages in thread From: Mario Emmenlauer @ 2020-10-01 10:22 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-01 10:22 ` Mario Emmenlauer @ 2020-10-06 1:41 ` Ken Brown 0 siblings, 0 replies; 12+ messages in thread From: Ken Brown @ 2020-10-06 1:41 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-09-22 20:14 test -r or -x always return false on an NFS mount? Mario Emmenlauer 2020-10-01 10:22 ` Mario Emmenlauer @ 2020-10-06 15:46 ` Andrey Repin 2020-10-06 16:10 ` Mario Emmenlauer 1 sibling, 1 reply; 12+ messages in thread From: Andrey Repin @ 2020-10-06 15:46 UTC (permalink / raw) To: Mario Emmenlauer, cygwin 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... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-06 15:46 ` Andrey Repin @ 2020-10-06 16:10 ` Mario Emmenlauer 2020-10-13 18:36 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Mario Emmenlauer @ 2020-10-06 16:10 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-06 16:10 ` Mario Emmenlauer @ 2020-10-13 18:36 ` Corinna Vinschen 2020-10-13 19:00 ` Mario Emmenlauer 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2020-10-13 18:36 UTC (permalink / raw) To: Mario Emmenlauer; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-13 18:36 ` Corinna Vinschen @ 2020-10-13 19:00 ` Mario Emmenlauer 2020-10-14 8:28 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Mario Emmenlauer @ 2020-10-13 19:00 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-13 19:00 ` Mario Emmenlauer @ 2020-10-14 8:28 ` Corinna Vinschen 2020-10-14 9:06 ` Mario Emmenlauer 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2020-10-14 8:28 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-14 8:28 ` Corinna Vinschen @ 2020-10-14 9:06 ` Mario Emmenlauer 2020-10-14 11:50 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Mario Emmenlauer @ 2020-10-14 9:06 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-14 9:06 ` Mario Emmenlauer @ 2020-10-14 11:50 ` Corinna Vinschen 2020-10-14 14:57 ` Mario Emmenlauer 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2020-10-14 11:50 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-14 11:50 ` Corinna Vinschen @ 2020-10-14 14:57 ` Mario Emmenlauer 2020-10-15 8:16 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Mario Emmenlauer @ 2020-10-14 14:57 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: test -r or -x always return false on an NFS mount? 2020-10-14 14:57 ` Mario Emmenlauer @ 2020-10-15 8:16 ` Corinna Vinschen 0 siblings, 0 replies; 12+ messages in thread From: Corinna Vinschen @ 2020-10-15 8:16 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-10-15 8:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-22 20:14 test -r or -x always return false on an NFS mount? Mario Emmenlauer 2020-10-01 10:22 ` Mario Emmenlauer 2020-10-06 1:41 ` Ken Brown 2020-10-06 15:46 ` Andrey Repin 2020-10-06 16:10 ` Mario Emmenlauer 2020-10-13 18:36 ` Corinna Vinschen 2020-10-13 19:00 ` Mario Emmenlauer 2020-10-14 8:28 ` Corinna Vinschen 2020-10-14 9:06 ` Mario Emmenlauer 2020-10-14 11:50 ` Corinna Vinschen 2020-10-14 14:57 ` Mario Emmenlauer 2020-10-15 8:16 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).