GNU bug report logs -
#17330
files.el cd-absolute overcome false negative from file-executable-p
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 3 years and 210 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.