[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: Sun, 11 May 2014 20:26:10 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

; cd to the 700 folder does not, this is clearly a false negative:
cd-absolute: Cannot cd to //  Permission

Why is that a false negative?  According to this:

$ icacls .
. S-1-5-32-766:(OI)(CI)(RX,W,WDAC,WO,DC)
    Everyone:(OI)(CI)(Rc,S,REA,RA)  <<<<<<<<<<<<<<<<<<<<

you indeed have no "execute/traverse" rights to this directory.  It is
possible that Cygwin doesn't DTRT with the S-1-5-32-766 well-known
SID, which is NT_BUILTIN_CURRENT_OWNER SID.  Perhaps it would be a
good idea to describe all this on the Cygwin mailing list.

It's a false negative because the folder belongs to the host user I connected as, and that user happens to be able to do anything with it, including cd, if only cd-absolute would actually try it. I'm not just "everyone", I also happen to be the owner. Of course in the general case there might be host groups involved too, or even host ACLs.

; in a shell cd to the same 700 folder works fine
$ cd //
$ ls
600  640  644  win

So the shell doesn't check, while Emacs does, so what?

Because cd and ls in that directory work in a cygwin shell, but opening and changing to that same directory do not work in cygwin emacs-w32.

$ icacls .
. S-1-5-32-766:(OI)(CI)(RX,W,WDAC,WO,DC)
Successfully processed 1 files; Failed processing 0 files

cygwin emacs-w32 emacs-version ""
   (file-executable-p "//")

Native builds do not seem to be affected:
native emacs-version "24.3.1"
   (file-executable-p "//")

Irrelevant: native Windows Emacs doesn't examine the ACLs, so it
simply has no way of knowing this.

However it got there, whether by guesswork or sheer optimism, it happened to come up with the right answer.

>> ...

I'm having a hard time understanding why you want to put so much faith
in functions that are not reliable now, and will be quite hard or even
genuinely impossible to make reliable in all of quite a large number of
more or less realistic test scenarios.

The functions are reliable.  It's just that you have some obscure
situation with the share owner, file/directory owner, and network
connection, and this combination bites you.  It might also be a Cygwin

They are subject to race conditions, false positives and false negatives. They are reliable only in the sense that they generally do return (unless the network hangs, is there any way to stay responsive when that happens?) and the answer is quite often a true positive or true negative.

But I'm tired of wading through all this, so if
file-accessible-directory-p does the trick for you, let's forget about
the rest.

I just skimmed through yet another tiring article about how there are fundamental reasons why cygwin can't always get permissions and ACLs exactly right, even without specifically mentioning remote SMB servers. I'm quite convinced the cygwin folks would have already done it if it was actually possible.

But I'm also curious about why different SMB implementations make a difference. If it was affecting Samba (recent with SMB2?) on GNU/Linux or Apple's own new SMB in MacOSX 10.9 (which defaults to SMB2.x) instead of just Oracle's Solaris (likely still SMB1) then would you still write it off as obscure? I didn't try a GNU/Linux yet by the way, it took me long enough just to find out how to configure a smb share on Solaris (with zfs commands on 11.2) and have virtualbox make it visible on my network (bridge).

I do appreciate your patience and tenacity. This thread just grew and grew longer against my expectations. I wish now that I had done more research and testing up front. And taken more care to note down or remember the getfacl command correctly, instead of recalling it as the typo fgetacl.

reply via email to

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