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.