public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin" <cygwin@cygwin.com>
To: "'cygwin@cygwin.com'" <cygwin@cygwin.com>
Subject: Re: SMBFS mount's file cannot be made executable
Date: Wed, 14 Aug 2019 20:39:00 -0000	[thread overview]
Message-ID: <BN6PR09MB1409241CD7F751EA43E8D0C0A5AD0@BN6PR09MB1409.namprd09.prod.outlook.com> (raw)

> See the '+' at the end of the modes?

I saw that, and I also showed the "getfacl" output for that file and the directory above, which showed
nothing additional.

> Maybe, but we'd still need to know how to get to the result you're seeing.

Just take a samba server (4.x) and mount a share with default settings on your Windows box; then
try to change the execute permissions for files in there from Cygwin's shell, using chmod -- the simplest.

> I hope it's clear to you that the permissions you see on this tab have
> nothing to do with the POSIX mode bits you're trying to set from Cygwin.

That is completely untrue;  the underlying filesystem is still controlled by the OS (Windows) in either case.
When the "x" permission is set from under Cygwin, it has to get converted (inside the Cygwin dll) to an appropriate
DAC for the native file system layer.  That DAC is then sent to the samba server (in case of the smb filesystem),
which then either converts it back to the "x" permission (when the SMBD is on Linux) or stores it on the target
filesystem, if that's a Windows box.

And it works the similar way in the reverse:  when a file stat is requested from Cygwin, the SMBD gets the "x" bit,
converts it to SMB response (native for Windows DAC for "execute") and sends it back to Windows box,
which is then read by Cygwin DLL and gets shown as "x" bit in the POSIX mode.  When I just use the file properties
dialog, I bypass only one step in the chains I just described, Cygwin DLL.  And it works by setting the "x" bit
on the server side (Linux).  So, that's how I know that something's off in how Cygwin treats that "x" permission
when asked to set it on a file.

When Windows is about to run an .exe file, it consults the filesystem whether the execute DAC is set.
In case of SMBD 4.x, the filesystem will respond "Access denied" if the "x" permission is not found.
It used to say "okay" in the previous versions.  I quoted the report:

https://forge.univention.org/bugzilla/show_bug.cgi?id=33785

So when I asked my Systems guys that the share to be exported with 

acl allow execute always = True

I can now execute any files (even those whose "x" bits are not set at all! -- SMBD clears everything to execute,
which is madness).  Well, that works around the issue for me, but the question remains as to why when "chmod +x" is given,
Cygwin does not cause the "x" permission to be set on the target file if that file resides on smbfs.
I suspect there are no provisions in code to do that, but I may be wrong.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

             reply	other threads:[~2019-08-14 20:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 20:39 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin [this message]
2019-08-15  1:31 ` Ken Brown
  -- strict thread matches above, loose matches on Subject: below --
2019-08-15  2:00 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-15  9:21 ` L A Walsh
2019-08-15  9:23 ` L A Walsh
2019-08-21  7:12   ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-15  1:40 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-15  2:59 ` Brian Inglis
2019-08-14 14:07 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-15  1:28 ` Ken Brown
2019-08-14  4:24 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-14 11:22 ` Ken Brown
2019-08-14 22:58   ` Brian Inglis
2019-08-14  0:53 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-14  2:36 ` Ken Brown
2019-08-14 16:59 ` Achim Gratz
2019-08-12 19:05 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-13  8:28 ` KAVALAGIOS Panagiotis (EEAS-EXT)
     [not found] ` <704986a5a4ab41709eb963dcd23887b1@BELBRU-EXMP101.eeas.europa.eu>
2019-08-13 12:27   ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-13 18:34     ` Achim Gratz
2019-08-13 18:35     ` Andrey Repin
2019-08-13 23:19       ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-08-14 20:05         ` Andrey Repin
2019-08-08 15:42 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin

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=BN6PR09MB1409241CD7F751EA43E8D0C0A5AD0@BN6PR09MB1409.namprd09.prod.outlook.com \
    --to=cygwin@cygwin.com \
    --cc=lavr@ncbi.nlm.nih.gov \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).