No support for ACLs on network shares?

No support for ACLs on network shares?

[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

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.

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?


Matt D.

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

Re: No support for ACLs on network shares?

[Andrey Repin]

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.


-- 
With best regards,
Andrey Repin
Monday, November 23, 2015 14:03:38

Sorry for my terrible english...


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

Re: No support for ACLs on network shares?

[Matt D.]

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

Re: No support for ACLs on network shares?

[Andrey Repin]

Greetings, Matt D.!

Please don't top-post. Thank you.

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

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

You are misunderstanding the meaning of "noacl" flag.
It doesn't mean that "ACL's are not supported", it means exactly what I wrote
- Cygwin will defer all control to the underlying OS.


-- 
With best regards,
Andrey Repin
Monday, November 23, 2015 16:15:35

Sorry for my terrible english...


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

Re: No support for ACLs on network shares?

[Linda Walsh]

Matt D. wrote:
> 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.
> 
----
So the remote server has a different user-database
than what is used for your Cygwin-on-windows machine?

I.e. username seems like it is 'private' to HOSTNAME.

So let's say your cygwin machine is (or is not) part of a domain.
If it is, it contacts the domain server to resolve sid's to
populate the local /etc/passwd database (in memory or on disk).
If it isn't, it contacts the local-host's name resolution routines
to do the same.

If you are not logging into 'HOSTNAME' as a DOMAIN user -- it's
a different user -- and how would cygwin know what the remote
system has setup for it's local-user database?

I.e. On a normal Winstation, users Winstation\user && Domain\user
are different SID's -- **except** on the DC.  So files I create
as 'user' on my Samba3-DC, are owned by 'Domain\User'.  If I login
to my local winstation (which is  part of /joined to the domain),
the default login space is 'Domain\' unless you override it with
a local host name -- then you get the local user.  And, BTW, I still
have 2 accounts on my Winstation -- one created before the winstation
was part of a domain, and the other created after.

Does this explain your situation, or is it something else completely?

Linda

P.s. - Your top-posting was pleasing, I got to read what you said 1st
instead of the quoted reply, which I'd already read....(people who tend to
jump in, in the middle of a conversation, really don't like top-posting
as it puts the onus on them to read prior posts in the thread).




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

Re: No support for ACLs on network shares?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

On Nov 23 04:28, Matt D. wrote:
> 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.

I don't know why that occurs.  I'd have expected to see something like
UnixUser+number at least.  However, the above is not the situation you
use winbind for.  Winbind maps Windows user accounts to Unix accounts,
but in the above case it's a real Unix account, not one of the mappings
used by Winbind.

Your case is tricky.  Windows doesn't care for the account, unless
you open the security tab in the properties dialog.  In that case
Explorer knows the share it's looking up and so knows which server
to ask for the account information.  In Cygwin this works differently.
Given the current flow of information, the account functions in Cygwin
only get told something like "please return a passwd entry for SID
S-1-x-y-z".  The functions don't know in which scenario the request
is performed, so it only asks the local machine for the SID, and the
local machine only looks into its own SAM, or in an AD environment
it's DC.  If those don't know the account, Cygwin has to handle this
account as unknown.  ANother way to dereference an account is by
utilizing the user mapping per RFC 2307 as outlined in
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba
The method described therein allows to map the Unix account to your
local Windows account, so from Cygwin's POV the files belong to your
Windows user.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]