X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=QgCjxjjkaStnQM5P
	W/u8AevtysIe8ojlD1ib94naKsPE9nUlq4P/AYpZBn+AI0E1n6mqtdr8fhg8JyyA
	L3Qsml5dnWUmne+rT5ymOlSFBc2AS99KhBFwe9CsbNZitYsgVn71CvHtdcVEMBT9
	z2XuhfS5Wt/4op9sjAA3vk4+aN4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=70kn4uqd9w3fikUSPQ+gEn
	8z9pg=; b=K0Pwsde2vRR6QTh3Ni75D3LkwKZR3UhZUFLlqBvDLPhAramBO55OBW
	lmdQVoe0yh8DyL7+6XCby6anruQgLKne6I/mm9tCaEId7RslzGDCw9cYVRQmKLoy
	gyQ6jLBsYgTqbL6qVXyA4lzjwZxtP9rO6Fy/Fr8HKQmAvFbeLYHSQ=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO: smtp.ht-systems.ru
Date: Mon, 23 Nov 2015 16:17:06 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <1683156931.20151123161706@yandex.ru>
To: "Matt D." <matt AT codespunk DOT com>, cygwin AT cygwin DOT com
Subject: Re: No support for ACLs on network shares?
In-Reply-To: <56530687.3090905@codespunk.com>
References: <5652E58A DOT 2030605 AT codespunk DOT com> <89802969 DOT 20151123140802 AT yandex DOT ru>   <56530687 DOT 3090905 AT codespunk DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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