Re: No support for ACLs on network shares?

["Matt D." <matt@codespunk.com>]

Andrey,

My samba server is configured to use winbind and when inspecting the 
file using explorer properties, the SIDs resolve correctly as:

"NAME (HOSTNAME\username)"

where "NAME" is my name on the unix account and "username" is my login.

The problem is that Cygwin isn't aware of this SID since it's the user I 
log in as to the remove server and isn't a local SID.

Using noacl is a valid workaround but I would prefer an ACL-supported 
solution if possible.


Matt D.

On 11/23/2015 3:08 AM, Andrey Repin wrote:
> Greetings, Matt D.!
>
>> I noticed today that when accessing a network share, the permissions for
>> the current user are not resolving.
>
>> For example, I'm connected to a network share //server/share which is a
>> CentOS share with a unix login/password. The share is already logged in
>> by Windows and on the keychain so I don't have to enter the login
>> information.
>
>> In Cygwin, 'cd //server/share' then 'ls -l' I get this:
>
>> drwxrwx---  1 Unknown+User Unix_Group+1001          0 Nov 23  2015 test
>
> This looks like a share on a Linux(samba) server with no UID mapping active.
>
>> I'm already logged in through windows as the 'Unknown+User' but Cygwin
>> does not recognize that I have access to any of the ACLs for the owner
>> or groups and also does not resolve the SID name.
>
> This is really not Cygwin's fault. Windows does all the resolution here,
> Cygwin only relay that information to you.
>
>> The problem with this is that files created or modified are only done so
>> in the 'Everyone' permission and inherited permissions such as the
>> execute bit are not recognized.
>
>> My use-case is where I've mapped a network path to either a network
>> drive or a symlinked folder (with Windows mklink) with the path on the
>> environment's PATH. In this case, files which are executable are not
>> recognized and do not appear when calling 'which'.
>
>> It seems as though Cygwin only maps ACLs to the SIDs stored in passwd
>> and group and cannot handle ACLs when accessing network devices where
>> SIDs are not present in these files. Running passwd/mkgroup after the
>> share is on the keychain does not provide additional SIDs.
>
>> Is there no support for ACLs across network shares at all?
>
> There is. But in cases such as this, when two hosts are not parts of the same
> domain, you are bound to get weird behavior in the strict security context.
> You may try defer default ACL resolutions to Windows.
> Edit your /etc/fstab, add the 'noacl' flag to a 'cygdrive' mount.
>
>

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