From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aldebaran.he1ix.org (aldebaran.he1ix.org [IPv6:2a01:4f8:173:803:0:a1de:ba:a]) by sourceware.org (Postfix) with ESMTP id 79EE73857C6F for ; Tue, 13 Oct 2020 19:00:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 79EE73857C6F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=emmenlauer.de Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=mario@emmenlauer.de Received: from ipbcc054c1.dynamic.kabel-deutschland.de ([188.192.84.193] helo=[192.168.1.190]) by aldebaran.he1ix.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1kSPWu-00060Q-J8 for cygwin@cygwin.com; Tue, 13 Oct 2020 21:00:13 +0200 To: cygwin@cygwin.com References: <1279009444.20201006184606@yandex.ru> <20201013183650.GW26704@calimero.vinschen.de> From: Mario Emmenlauer X-Tagtoolbar-Keys: D20201013210012095 Message-ID: <2820bfde-68f4-e2f9-78c4-4174423a6213@emmenlauer.de> Date: Tue, 13 Oct 2020 21:00:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201013183650.GW26704@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 188.192.84.193 X-SA-Exim-Mail-From: mario@emmenlauer.de X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, TXREP, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 Subject: Re: test -r or -x always return false on an NFS mount? X-SA-Exim-Version: 4.2.1 (built Sun, 08 Nov 2009 07:31:22 +0000) X-SA-Exim-Scanned: Yes (on aldebaran.he1ix.org) X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 19:00:16 -0000 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