delorie.com/archives/browse.cgi | search |
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 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |