[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Philip Hodges
Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p
Date: Sat, 03 May 2014 11:17:43 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]