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

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

[Philip Hodges]

[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.

A workaround is to make my directory and its parents executable for "others",
but of course it would be much better to keep the correct mode in force.
Maybe a more recent or better configured samba on the server would help.

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.

Suggested fix:
In files.el the function cd-absolute can ask for confirmation in case
check-executable-p might be producing a false negative:

;; in emacs-24.3/lisp/files.el [cd-absolute] replace the expression
    (unless (file-executable-p dir)
      (error "Cannot cd to %s:  Permission denied" dir))
;; with
    (unless (file-executable-p dir)
      (unless (yes-or-no-p
			   (format
				"Directory does not look searchable; try to cd to %s anyway? "
				dir))
		(error "Cannot cd to %s:  Permission denied" dir)))

I encountered the cd failure originally on invoking ediff-files to merge
source code from a samba mount, then noticed cd itself is affected too.
I haven't run into any other false negative cases.
The 24.3 distribution contains about 50 calls to
file-executable-p where a fix like this might potentially be useful,
not to mention custom code and community packages, and other similar functions.

In directory search contexts file-searchable-p might be a better name.

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

[Glenn Morris]

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?).

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

[Philip Hodges]

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.

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

[Achim Gratz]

Philip Hodges writes:
> 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.

Cygwin also uses euidaccess (or should, anyway):
http://cygwin.com/ml/cygwin/2011-12/msg00364.html

But yes, you can totally have full access to a directory or file on a
Windows box while all permission flags show that you don't (I guess that
is also possible on UN*X, although I've never tried).  You'll never know
until you actually try.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sat, 03 May 2014 11:35:01 +0200
> 
> But yes, you can totally have full access to a directory or file on a
> Windows box while all permission flags show that you don't (I guess that
> is also possible on UN*X, although I've never tried).  You'll never know
> until you actually try.

That's true (on Windows; I don't think it's possible on Unix), but why
is that an Emacs problem?  I think this problem should be communicated
to the Cygwin maintainers: an accessible directory should return
success from the faccessat call, because otherwise Posix-originated
programs such as Emacs will misbehave.

If the Cygwin maintainers will decide that this specific situation
(whose particulars as far as Windows ACL data of the directory in
question was never shown by the OP, by the way), then this would mean
it's either a cockpit error (i.e. the user shoot himself in the foot
by creating a security descriptor he shouldn't have), or that Cygwin
does not intend to support such situations in the first place.  Either
way, Emacs is not to blame here.

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

[Eli Zaretskii]

> 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"

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

[Achim Gratz]

Eli Zaretskii writes:
> If the Cygwin maintainers will decide that this specific situation
> (whose particulars as far as Windows ACL data of the directory in
> question was never shown by the OP, by the way), then this would mean
> it's either a cockpit error (i.e. the user shoot himself in the foot
> by creating a security descriptor he shouldn't have), or that Cygwin
> does not intend to support such situations in the first place.

Cygwin already has the "noacl" mount option which fakes the uid/gid and
permissions for that file system so that they always look sane from the
POSIX perspective and then you'll find out when you access the file
whether you have access.  While it's generally a sign of some
problematic configuration someplace else and introducing some other
problems when you have to use it, the OP could maybe tell us if that
makes a difference to the reported problem.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sat, 03 May 2014 15:58:05 +0200
> 
> Eli Zaretskii writes:
> > If the Cygwin maintainers will decide that this specific situation
> > (whose particulars as far as Windows ACL data of the directory in
> > question was never shown by the OP, by the way), then this would mean
> > it's either a cockpit error (i.e. the user shoot himself in the foot
> > by creating a security descriptor he shouldn't have), or that Cygwin
> > does not intend to support such situations in the first place.
> 
> Cygwin already has the "noacl" mount option which fakes the uid/gid and
> permissions for that file system so that they always look sane from the
> POSIX perspective and then you'll find out when you access the file
> whether you have access.

Yes, I know.  But it's not clear to me at this point that the only
reasonable way out of this is by using "noacl".

> While it's generally a sign of some problematic configuration
> someplace else and introducing some other problems when you have to
> use it, the OP could maybe tell us if that makes a difference to the
> reported problem.

Indeed, having more details about the ACLs of the offending
directories would be good.

bug#17330: thanks for the comments

[Philip Hodges]

thanks for all the discussion contributions.

I'm really happy about having my own personal same day lisp fix working for me to stop cd-absolute believing the false negative from the check_executable function. My best hope for the remaining subprocess cwd cases is to look at the samba configuration and see if I can get it improved, and maybe add a user to the cygwin passwd file.

Anything involving a rebuild and new release will take months before it is available for me to use where I need it.

For completeness, and in the spirit of DRY, whatever uses start-process and call-process *could* be refactored to share the same code to offer the same override as file-executable-p in the same situation. And while we are about it, can we please not ask if a file is executable when we really just want to know if it is a searchable directory suitable for cd.

I don't see how we can ever completely rule out false negatives, unless we are prepared to change check_executable to actually try to use the directory (cd to it, open it, list its entries, return t, whatever). Even the euidaccess man page warns against using it: "Generally, it is safer just to attempt the desired operation and handle any permission error that occurs". But I do accept that there may well be no consensus to follow through with more reliable or less gullible code. If it is just a few legacy platforms that lack euidaccess and fall back to checking the wrong uid with access, then never mind. If we can prove that the native and cygwin builds behave differently, then the offending library function can probably be fixed long before emacs can work around it. Thank you for pushing that suggestion.

My samba share is also afflicted with false negative writeable checks, as described here two years ago:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10257

I connect to the samba filesystem directly in Windows as a user without local administrator rights. I'll let you know if mounting it from cygwin with special acl options confers more appropriate access permissions or even works at all.

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

[Glenn Morris]

I'm finding this rather abstract.
I think a reproducible example of the same kind of issue on a Unix
platform would be helpful.

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

[Stefan Monnier]

> I'm finding this rather abstract.  I think a reproducible example of
> the same kind of issue on a Unix platform would be helpful.

It's probably somewhere between hard and impossible to reproduce on
a Unix platform.

The problem is that cd-absolute wants to signal an error if the
directory specified can't be used, whereas within Emacs any string can
be used for the "current directory" (it's just that some choices lead
to errors later on, such as when trying to get to a relative-named file
or when trying to spawn a process).

AFAIK, the only moment where Emacs cares whether the OS can use
something as a current directory (i.e. when it does "chdir") is when it
spawn a process via call-process or start-process.

So, we could solve this problem either by dropping this error, or by
using call-process instead of file-executable-p.  Yet another way would
be to provide a new subroutine that gives access to chdir somehow
(e.g. "file-chdirable-p").

I think the simplest solution for now is to turn the error into a warning.


        Stefan

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

[Philip Hodges]

I came across a post that confirms my suspicions that:
- the _stat st_mode bits really cannot be trusted to give a meaningful answer, no matter whether it comes from Windows or cygwin.
- it is not worth calling GetFileSecurity (which is what I meant by "something like GetFileAttributes" *) and trying to reproduce the interpretation of the ACL information
- the best way is to find out if searching a directory will succeed really is to actually try it

http://stackoverflow.com/questions/3449465/find-the-permissions-of-a-file-in-windows

> ... somewhere between hard and impossible to reproduce ...
To reproduce on any platform, simply change check_executable to *always* return false. The easiest way to test what happens with false negatives is to have negatives all the time.

The more I read about it and think about it, the more I stand by my original change suggestion: tell the user that the directory might not be searchable, ask them if they want to go ahead and try it anyway. And also ask if they always want to do that, in case the question appears so often that it becomes annoying. I think we have to accept and work with what we have got instead of punishing users until such time as every possible combination of filesystem and library methods can be upgraded in a way that might not even be practical for many of them.

Surely the worst that can happen is that it becomes easier to end up with a buffer whose current directory really is not searchable, or file changes that cannot be saved in the original location. Good to avoid, but not vital. Rather that than being completely denied the use of a feature such as ediff-directories that would actually work.

Much of what was written for #10257 (writeable) applies to this #17330 (searchable directory) and vice versa. So if we are only comfortable with just treating a -1 uid or gid specially here too, well it is not a general solution, but better than no change at all. Having just the default entries in the passwd file hasn't been causing me any other noticeable trouble.

[*) If I have mixed up any other detail such as which conditional compiling macros are defined to choose between euidaccess and stat or _stat in which builds, or misreported something observed on a system that is not in front of me at that moment, please forgive me.]

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 04 May 2014 09:01:12 -0400
> Cc: Philip Hodges <philip.hodges@bluewin.ch>, 17330@debbugs.gnu.org
> 
> So, we could solve this problem either by dropping this error, or by
> using call-process instead of file-executable-p.

Which program would you invoke for this?

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

[Eli Zaretskii]

> From: Philip Hodges <philip.hodges@bluewin.ch>
> Date: Sun, 4 May 2014 15:24:35 +0200
> 
> I came across a post that confirms my suspicions that:
> - the _stat st_mode bits really cannot be trusted to give a meaningful answer, no matter whether it comes from Windows or cygwin.
> - it is not worth calling GetFileSecurity (which is what I meant by "something like GetFileAttributes" *) and trying to reproduce the interpretation of the ACL information
> - the best way is to find out if searching a directory will succeed really is to actually try it
> 
> http://stackoverflow.com/questions/3449465/find-the-permissions-of-a-file-in-windows

You still didn't provide any details about your particular situation
which triggers this problem.  Would you _please_ do that?

If is very hard to conduct a meaningful discussion without a clear
understanding of the problem.  Maybe you are right in your analysis,
but without actually seeing the ACLs of the related directories, we
cannot be sure that your analysis is correct and complete.  Given the
details, we could reason about the problem and maybe consult with some
experts if the knowledge we have here is insufficient.  That would
make this discussion much more productive, and a satisfactory solution
will probably be found quickly enough.

Thanks in advance.

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

[Glenn Morris]

Stefan Monnier wrote:

> So, we could solve this problem either by dropping this error, or by
> using call-process instead of file-executable-p.  Yet another way would
> be to provide a new subroutine that gives access to chdir somehow
> (e.g. "file-chdirable-p").

I'd still like to hear if file-accessible-directory-p does any better
than file-executable-p. At least on !DOS_NT, it seems to be something a
bit different.

> I think the simplest solution for now is to turn the error into a warning.

Sounds good, but might be annoying on Unix platforms; if as you say
this situation is impossible there an error might be clearer for them.

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

[Stefan Monnier]

> I'd still like to hear if file-accessible-directory-p does any better
> than file-executable-p. At least on !DOS_NT, it seems to be something a
> bit different.

Indeed file-accessible-directory-p would probably be better than
file-executable-p.  Whether it's sufficiently better to keep the error,
I don't know.

>> I think the simplest solution for now is to turn the error into a warning.
> Sounds good, but might be annoying on Unix platforms; if as you say
> this situation is impossible there an error might be clearer for them.

Agreed.


        Stefan

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

[Philip Hodges]

After discovering that even C functions can be redefined, today I "activated an advice" so that all file-executable-p C code calls from Lisp return t.
No unexpected refusals, no noticeable downsides, no waiting months for C code changes to appear in a new official release. The solution is satisfactory in practice. So far as I am concerned, the case can be closed. Can we at least document the unreliability first though?

From the cygwin FAQ: "When working out the Unix-style attribute bits on a file, the library has to fill out some information not provided by the WIN32 API. It *guesses* ..."

I understand your being curious as to exactly why cygwin cannot guess correctly for this samba mount without going to an awful lot of trouble. But we do already have several statements confirming that it is not usual or practical to even try. These make sense to me. They explain and confirm what I am seeing. The analysis does not need to be complete. It just takes one reproducible false negative in a realistic scenario that is not going to go away anytime soon. At least one of the platform library functions called by file-executable-p sometimes cannot be trusted. That's enough for me. Let's stop trusting it at all.

We could soften all these file permission functions to ask the user if they want to try anyway. Then the next person won't have to figure out the checks are unreliable and how to override them. I'll try running with that for the next few days.

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

[Glenn Morris]

I would *still* like to hear if file-accessible-directory-p does any
better than file-executable-p. The result is only interesting in an
Emacs later than 24.3. Eg 24.3.90 pretest, or current trunk or emacs-24
branch. (Since we have no recipe to reproduce this problem, no-one else
can say.)

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

[Eli Zaretskii]

> From: Philip Hodges <philip.hodges@bluewin.ch>
> Date: Tue, 6 May 2014 00:43:27 +0200
> Cc: 17330@debbugs.gnu.org
> 
> After discovering that even C functions can be redefined, today I "activated an advice" so that all file-executable-p C code calls from Lisp return t.
> No unexpected refusals, no noticeable downsides, no waiting months for C code changes to appear in a new official release. The solution is satisfactory in practice. So far as I am concerned, the case can be closed. Can we at least document the unreliability first though?

I don't know what to document, since you never disclosed the details.
Good documentation should not include FUD, it should include details
that are understandable and actionable by users.  Writing such
documentation requires a good understanding of your situation,
something we don't have in this case.

> From the cygwin FAQ: "When working out the Unix-style attribute bits on a file, the library has to fill out some information not provided by the WIN32 API. It *guesses* ..."

That's not directly related to the case in point, AFAIK (and yes, I do
know what Cygwin does to emulate Posix permissions using Windows
ACLs).

> I understand your being curious as to exactly why cygwin cannot guess correctly for this samba mount without going to an awful lot of trouble. But we do already have several statements confirming that it is not usual or practical to even try. These make sense to me. They explain and confirm what I am seeing. The analysis does not need to be complete. It just takes one reproducible false negative in a realistic scenario that is not going to go away anytime soon. At least one of the platform library functions called by file-executable-p sometimes cannot be trusted. That's enough for me. Let's stop trusting it at all.

It is a pity that you don't tell the details.  The result will be that
the problem is perhaps solved for you (using a recipe that many Emacs
users will not know how to reproduce), but not for others.  I urge you
to reconsider.  After all, the amount of words we've wasted here is
surely large enough to describe your issue to the required depth.

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

[Stefan Monnier]

> After discovering that even C functions can be redefined, today I "activated
> an advice" so that all file-executable-p C code calls from Lisp return t.
> No unexpected refusals, no noticeable downsides, no waiting months for
> C code changes to appear in a new official release.

The changes being discussed are to `cd-absolute' which is an Elisp
function, so no need for recompilation.

E.g. if you add

   (defun cd-absolute (dir)
     "Change current directory to given absolute file name DIR."
     ;; Put the name into directory syntax now,
     ;; because otherwise expand-file-name may give some bad results.
     (setq dir (file-name-as-directory dir))
     ;; We used to additionally call abbreviate-file-name here, for an
     ;; unknown reason.  Problem is that most buffers are setup
     ;; without going through cd-absolute and don't call
     ;; abbreviate-file-name on their default-directory, so the few that
     ;; do end up using a superficially different directory.
     (setq dir (expand-file-name dir))
     (if (not (file-directory-p dir))
         (if (file-exists-p dir)
   	  (error "%s is not a directory" dir)
   	(error "%s: no such directory" dir))
       (unless (file-accessible-directory-p dir)
         (error "Cannot cd to %s:  Permission denied" dir))
       (setq default-directory dir)
       (setq list-buffers-directory dir)))

to your .emacs, does it fix the problem for you?


        Stefan

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

[Glenn Morris]

Stefan Monnier wrote:

> to your .emacs, does it fix the problem for you?

(In an Emacs later than 24.3; ie one where file-accessible-directory-p
is not just file-directory-p && file-executable-p.)

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

[Glenn Morris]

>> I'd still like to hear if file-accessible-directory-p does any better
>> than file-executable-p.

I got tired of asking, so I simply changed it to use the former anyway,
since it can't be any worse than the latter and might be better.

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

[Philip Hodges]

On 2014-05-06 18:56, Glenn Morris wrote:
> Stefan Monnier wrote:
>
>> to your .emacs, does it fix the problem for you?
>
> (In an Emacs later than 24.3; ie one where file-accessible-directory-p
> is not just file-directory-p && file-executable-p.)

I can confirm that cd-absolute calling file-accessible-directory-p in 
emacs-w32 24.3.90 permits cd to a 700 folder on my Solaris 11.2 share.

Is there a way to have the process functions call it without rebuilding?