From: Philip Hodges <philip.hodges@bluewin.ch>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 17330@debbugs.gnu.org
Subject: bug#17330: files.el cd-absolute overcome false negative from file-executable-p
Date: Sun, 11 May 2014 20:26:10 +0200 [thread overview]
Message-ID: <536FC0C2.6080300@bluewin.ch> (raw)
In-Reply-To: <837g5suu67.fsf@gnu.org>
>> ; 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.
next prev parent reply other threads:[~2014-05-11 18:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E6923B15-B9A8-4B3C-ADDF-713810613ADD@bluewin.ch>
2014-05-07 18:15 ` bug#17330: files.el cd-absolute overcome false negative from file-executable-p 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 [this message]
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
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-04-23 20:54 ` Philip Hodges
2014-05-03 0:24 ` Glenn Morris
2014-05-03 9:17 ` Philip Hodges
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-06 4:15 ` Glenn Morris
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
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=536FC0C2.6080300@bluewin.ch \
--to=philip.hodges@bluewin.ch \
--cc=17330@debbugs.gnu.org \
--cc=eliz@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.