GNU bug report logs -
#17330
files.el cd-absolute overcome false negative from file-executable-p
Previous Next
Full log
Message #92 received at 17330 <at> debbugs.gnu.org (full text, mbox):
>> ; cd to the 700 folder does not, this is clearly a false negative:
>> cd-absolute: Cannot cd to //192.168.0.18/myshare/smb/700/: Permission
>> denied
>
> Why is that a false negative? According to this:
>
>> $ icacls .
>> . S-1-5-32-766:(OI)(CI)(RX,W,WDAC,WO,DC)
>> S-1-5-32-767:(OI)(CI)(Rc,S,REA,RA)
>> 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 //192.168.0.18/myshare/smb/700
>> $ 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)
>> S-1-5-32-767:(OI)(CI)(Rc,S,REA,RA)
>> Everyone:(OI)(CI)(Rc,S,REA,RA)
>> Successfully processed 1 files; Failed processing 0 files
>>
>> cygwin emacs-w32 emacs-version "24.3.90.1"
>> (file-executable-p "//192.168.0.18/myshare/smb/700")
>> nil
>>
>> Native builds do not seem to be affected:
>> native emacs-version "24.3.1"
>> (file-executable-p "//192.168.0.18/myshare/smb/700")
>> t
>
> 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
> issue.
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.
This bug report was last modified 3 years and 211 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.