From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p Date: Sat, 03 May 2014 16:40:40 +0300 Message-ID: <831twb0ylj.fsf@gnu.org> References: <41559D99-B080-4B34-B491-3A811FA9FEAE@bluewin.ch> <5364B437.2070106@bluewin.ch> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1399124491 11769 80.91.229.3 (3 May 2014 13:41:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 May 2014 13:41:31 +0000 (UTC) Cc: 17330@debbugs.gnu.org To: Philip Hodges Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 03 15:41:21 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 1WgaBo-00041b-Sa for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 May 2014 15:41:17 +0200 Original-Received: from localhost ([::1]:49033 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgaBo-00021c-AS for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 May 2014 09:41:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgaBg-0001Vs-FY for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 09:41:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgaBb-00067h-8c for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 09:41:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60094) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgaBb-00067V-50 for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 09:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WgaBa-0001H1-Lk for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 09:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 May 2014 13:41: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.13991244344838 (code B ref 17330); Sat, 03 May 2014 13:41:02 +0000 Original-Received: (at 17330) by debbugs.gnu.org; 3 May 2014 13:40:34 +0000 Original-Received: from localhost ([127.0.0.1]:49212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgaB6-0001Fv-VB for submit@debbugs.gnu.org; Sat, 03 May 2014 09:40:33 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:56463) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgaB3-0001Fa-An for 17330@debbugs.gnu.org; Sat, 03 May 2014 09:40:30 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N50008002SPF500@a-mtaout23.012.net.il> for 17330@debbugs.gnu.org; Sat, 03 May 2014 16:40:22 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N50008JN3BAA780@a-mtaout23.012.net.il>; Sat, 03 May 2014 16:40:22 +0300 (IDT) In-reply-to: <5364B437.2070106@bluewin.ch> X-012-Sender: halo1@inter.net.il 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:88586 Archived-At: > Date: Sat, 03 May 2014 11:17:43 +0200 > From: Philip Hodges > Cc: 17330@debbugs.gnu.org > > 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. As Achim correctly points out, this doesn't matter, because on Windows a directory can be accessible to you by virtue of your belonging to certain user groups (like Power Users etc.), even though all the ACEs in that directory's security descriptor deny you any access. > Calling something like GetFileAttributes might give a truer picture No, it won't: GetFileAttributes does not return any access rights, only the file's attributes. IOW, it could tell that the file is a directory, but not if the directory is accessible to this or that user. > Would simply opening the directory, or starting a directory entries > listing, be more reliable, or too slow? If you try cd'ing, you might be unable to distinguish between an existing file that is not a directory and an inaccessible directory. Not sure if that is important here, I didn't analyze the users of cd-absolute. (Opening a directory is non-portable, and furthemore will not necessarily tell you that it can be listed -- these are different privileges on Windows.) > 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. Why not ask Cygwin maintainers to cover these situations in their euidaccess and/or faccessat implementations? Why should Emacs solve this for you, when it works on any other Posix platforms (and on some non-Posix ones)? Unlike the native Windows port of Emacs, the Cygwin build relies on a free library whose sources are freely available and can be fixed if a bug there is found and reported. So that's what I suggest to do -- report this to the Cygwin maintainers, and ask them to fix this. > 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? You will have endless such problems if accessible directories don't pass the test by euidaccess or access. This _must_ be fixed in the Cygwin library, or by your changing the permissions of those directories so that they are reported as executables. > A process does not necessarily even always have or need a current > directory (for example MacOS before MacOSX). It does in Emacs, because Emacs frequently (if not always) invokes programs in the context of an Emacs buffer, which conceptually (from the user POV) means the program should run in that buffer's directory. > Why does a directory even have to exist to use it to expand a > relative pathname? It doesn't: (expand-file-name "../doesntexist/anotherfake/foobar") => "d:/gnu/bzr/emacs/doesntexist/anotherfake/foobar"