bug#17330: files.el cd-absolute overcome false negative from file-executable-p

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 03 May 2014 11:17:43 +0200
> From: Philip Hodges <philip.hodges@bluewin.ch>
> 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"