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: No support for ACLs on network shares?


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


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