From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philip Hodges Newsgroups: gmane.emacs.bugs Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p Date: Sat, 03 May 2014 11:17:43 +0200 Message-ID: <5364B437.2070106@bluewin.ch> References: <41559D99-B080-4B34-B491-3A811FA9FEAE@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1399108711 15418 80.91.229.3 (3 May 2014 09:18:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 May 2014 09:18:31 +0000 (UTC) Cc: 17330@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 03 11:18:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WgW5O-0005VR-Jn for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 May 2014 11:18:22 +0200 Original-Received: from localhost ([::1]:48077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgW5N-0002Rw-Vy for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 May 2014 05:18:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgW5D-0002Rp-3R for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 05:18:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgW54-0008BU-PT for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 05:18:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgW54-0008BQ-MX for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 05:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WgW54-0001W0-5r for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 05:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Hodges Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 May 2014 09:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17330 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17330-submit@debbugs.gnu.org id=B17330.13991086705802 (code B ref 17330); Sat, 03 May 2014 09:18:02 +0000 Original-Received: (at 17330) by debbugs.gnu.org; 3 May 2014 09:17:50 +0000 Original-Received: from localhost ([127.0.0.1]:49103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgW4r-0001VU-Dc for submit@debbugs.gnu.org; Sat, 03 May 2014 05:17:49 -0400 Original-Received: from zhbdzmsp-smta15.bluewin.ch ([195.186.99.132]:42339) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgW4o-0001VC-RZ for 17330@debbugs.gnu.org; Sat, 03 May 2014 05:17:47 -0400 Original-Received: from [195.186.227.130] ([195.186.227.130:36498] helo=zhhdzmsp-smta12.bluewin.ch) by zhbdzmsp-smta15.bluewin.ch (envelope-from ) (ecelerity 3.5.7.40067 r(Platform:3.5.7.0)) with ESMTP id CB/32-15424-434B4635; Sat, 03 May 2014 09:17:40 +0000 Original-Received: from [192.168.0.13] (46.127.159.181) by zhhdzmsp-smta12.bluewin.ch (8.5.142) (authenticated as philip.hodges) id 52A87E3C09498DD9; Sat, 3 May 2014 09:17:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:88581 Archived-At: On 2014-05-03 02:24, Glenn Morris wrote: > Philip Hodges wrote: > >> [using emacs-w32.exe 24.3 in cygwin but also applies to other platforms.] >> >> Symptom: >> When I try to cd to my samba-mounted directory, >> or try to run ediff-files, it refuses with the error >> "Cannot cd to my_directory_name: Permission denied" >> The same directory opens fine in dired-mode, and I can open files within it. > >> This is just one way in which file-executable-p can produce a false negative, >> where executing the file or searching the directory may succeed after all. >> >> [False positives, where the operation refuses, have no impact so long as >> the operation fails quickly with an equivalent but authoritative error message.] >> >> This is typical of many situations where it is not good enough just >> to check quickly whether it just looks like it can or cannot be done; >> you have to also actually try it, and report the outcome of >> that particular attempt at that particular moment. >> A preliminary check may still be useful too if it produces a better error >> message quickly up front with no dashed expectations or cleaning up to do. >> >> The comments in fileio.c check_executable (and check_writeable) point out >> that on some filesystems there might be an access control list (ACL) in force, >> and that the effective user might have more permission than the real user. > > > Perhaps there is something Cygwin-specific at work, because I don't > think I can reproduce such a problem on eg RHEL 6.5 GNU/Linux. > > As user A: > mkdir foo1 foo2 > chmod 700 foo1 foo2 > setfacl -m u:b:r-x foo1 > > As user B: > In the shell: [ -x foo1 ] # -> true > > In Emacs 24.3: file-executable-p foo1 ; -> true > > > (There's also file-accessible-directory-p; does that work any better for > you?). > Your example platform likely has euidaccess and so takes the effective user id and ACL into account. Thanks for checking. I'm glad it works. Otherwise fileio.c:check_executable calls access which ignores any effective id, or looks at bits returned by stat. Calling something like GetFileAttributes might give a truer picture, but apparently there are several different ways the id(s) a user has can be permitted to access files in a directory, so interpreting the results might not be easy. Would simply opening the directory, or starting a directory entries listing, be more reliable, or too slow? In the end what counts is whether listing the directory at a particular moment actually works. To concoct a hopefully absurd example, the directory might be on a filesystem that has been cracked to grant directory listing access to guest users during NSA overnight batch job hours. There is no way a security audit system calling check_executable on an arbitrary client system can possibly discover that. Samba can be configured to allow or deny various kinds of access to various users, and to map the permission bits in artificial ways. The host access and client access permissions actually applied can differ wildly from what stat returns. I dare say the configuration of my samba share can be improved, but I think there will still be valid use cases as well as misconfigurations where false negatives cannot be completely ruled out. I'm happy that ediff-directories works for my samba folder when I tell it to let me override the outcome of check_executable and cd to it anyway. If I do cd to a directory that is genuinely not searchable, which I think would be something I could always avoid, the question actually helps me think about how I got there and whether it really is correct that I don't seem to have access. It's not the whole story. There are still circumstances where I get a slightly different error message about no permission to set current directory, after callproc.c:call-process or proc.c:start-process calls file-accessible-directory-p. It is C code calling C code, I don't suppose it can be intercepted in Lisp? A process does not necessarily even always have or need a current directory (for example MacOS before MacOSX). It might not even use relative filenames that need prefixing at all. Why does a directory even have to exist to use it to expand a relative pathname? Is Macavity's parent ever there? (That cat is free as in spirit, not as in beer). Do all GNU/Linux processes inevitably open the current directory for read? Does Windows open it and keep a handle, does it fail if it cannot? I will have to experiment and find out. The function file-accessible-directory-p is more appropriately named for this context but it is not better. It just checks for a directory first before calling file-executable-p and hence check_executable.