This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SMBFS mount's file cannot be made executable

> 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:

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]