From: Philip Hodges <philip.hodges@bluewin.ch>
To: Glenn Morris <rgm@gnu.org>
Cc: 17330@debbugs.gnu.org
Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p
Date: Sat, 03 May 2014 11:17:43 +0200 [thread overview]
Message-ID: <5364B437.2070106@bluewin.ch> (raw)
In-Reply-To: <v4n17btgb.fsf@fencepost.gnu.org>
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.
next prev parent reply other threads:[~2014-05-03 9:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 20:54 bug#17330: files.el cd-absolute overcome false negative from file-executable-p Philip Hodges
2014-05-03 0:24 ` Glenn Morris
2014-05-03 9:17 ` Philip Hodges [this message]
2014-05-03 9:35 ` Achim Gratz
2014-05-03 13:26 ` Eli Zaretskii
2014-05-03 13:58 ` Achim Gratz
2014-05-03 16:37 ` Eli Zaretskii
2014-05-03 13:40 ` Eli Zaretskii
2014-05-04 4:16 ` Glenn Morris
2014-05-04 13:01 ` Stefan Monnier
2014-05-04 16:18 ` Eli Zaretskii
2014-05-04 18:07 ` Glenn Morris
2014-05-04 22:44 ` Stefan Monnier
2014-05-09 6:54 ` Glenn Morris
2014-05-03 22:43 ` bug#17330: thanks for the comments Philip Hodges
2014-05-04 13:24 ` bug#17330: files.el cd-absolute overcome false negative from file-executable-p Philip Hodges
2014-05-04 16:24 ` Eli Zaretskii
2014-05-05 22:43 ` Philip Hodges
2014-05-06 7:17 ` Eli Zaretskii
2014-05-06 12:46 ` Stefan Monnier
2014-05-06 16:56 ` Glenn Morris
2014-05-11 13:55 ` Philip Hodges
2014-05-06 4:15 ` Glenn Morris
[not found] <E6923B15-B9A8-4B3C-ADDF-713810613ADD@bluewin.ch>
2014-05-07 18:15 ` Eli Zaretskii
2014-05-08 5:55 ` Philip Hodges
2014-05-08 7:09 ` Glenn Morris
2014-05-08 16:18 ` Eli Zaretskii
2014-05-11 10:46 ` Philip Hodges
2014-05-11 17:00 ` Eli Zaretskii
2014-05-11 18:26 ` Philip Hodges
2014-05-11 18:38 ` Glenn Morris
2014-05-11 21:59 ` Philip Hodges
2014-05-12 7:10 ` Glenn Morris
2014-05-12 7:26 ` Philip Hodges
2021-10-23 5:09 ` Stefan Kangas
2014-05-11 18:43 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5364B437.2070106@bluewin.ch \
--to=philip.hodges@bluewin.ch \
--cc=17330@debbugs.gnu.org \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.