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:from:to:subject:references:date:in-reply-to | |
:message-id:mime-version:content-type; q=dns; s=default; b=JIeTv | |
4M0QYzcnmXuwDvo287d3mOoO3L+x0pJf0ayIcRb54k9EdPj1AQehKUe50Lwbdet/ | |
Zjrk/I4tcNg/IN0AUPdpaasd/0BF+UAFZ6IQ7wtu2yR0toNLtC6rEMW4RXGs2uAp | |
vWMT+eQr7IxsU2UAo6dqFWBALceSS1xepmJ+Ok= | |
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:from:to:subject:references:date:in-reply-to | |
:message-id:mime-version:content-type; s=default; bh=kaQybqQvIS0 | |
CuwT0SVExFDT5F94=; b=u10EVYIMYVeOLQ54M0AOBJFFT+krQ6xjoP0T+QNZASO | |
MXVdu2pSebbuEIbQlDkq8IVNVw3YAKkynU2nEN+d6ml+cGdtCqMiYxULxbeNTNjF | |
f7I0ZJQuev7Wivh+kzpPC+DLmofoc6PUtksAxU9nQHx3Z1mw/Q73pnpLrUV8Sr5k | |
= | |
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=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 |
X-HELO: | mail-in-02.arcor-online.net |
X-DKIM: | Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 3msb283YTLz90HB |
From: | Achim Gratz <Stromeko AT nexgo DOT de> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: Shares with strange ACL settings |
References: | <loom DOT 20150811T101658-176 AT post DOT gmane DOT org> <20150812152601 DOT GL13029 AT calimero DOT vinschen DOT de> <loom DOT 20150812T172703-7 AT post DOT gmane DOT org> <20150812155817 DOT GN13029 AT calimero DOT vinschen DOT de> <878u9g9y6b DOT fsf AT Rainer DOT invalid> <20150812183220 DOT GO13029 AT calimero DOT vinschen DOT de> <87vbck8h92 DOT fsf AT Rainer DOT invalid> <20150813163302 DOT GB28349 AT calimero DOT vinschen DOT de> |
Date: | Thu, 13 Aug 2015 19:47:08 +0200 |
In-Reply-To: | <20150813163302.GB28349@calimero.vinschen.de> (Corinna Vinschen's message of "Thu, 13 Aug 2015 18:33:02 +0200") |
Message-ID: | <87egj7w06b.fsf@Rainer.invalid> |
User-Agent: | Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
MIME-Version: | 1.0 |
Note-from-DJ: | This may be spam |
Corinna Vinschen writes: > This puzzles me a bit. As example you gave something like > > ----rwx---+ gratz Domain Users [...] foo > > Given the code in recent Cygwin versions, this shouldn't happen if the > user gratz is member of the Domain Users group. The current code > doesn't test all groups in the ACL, only the primary group, but that's > sufficient in most cases. I've detailed the setup in an earlier post (with getfacl and icacls output) that I can't dig out shortly, but the setup is, in a nutshell: The share access is purely governed by two access groups, one that gives you the right to read and another one that lets you create and change things. You'll be in one or both of these groups in AD. All ACL are inherited from the root of the share down and the right to change the DACL (and thus remove that inheritance) is explicitly forbidden for anybody. The actual setup is a bit more complicated, with additional groups that ensure that share administrators can do what they need to do and that the backup can actually be done, etc.pp. > So this could only happen if you modify the permissions of windows files > using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the > owner. No, the owner just never gets the full access it would need to do this. For a while they didn't even let you look at the DACL, but at least that part of the silliness has been fixed. > I'm just not exactly sure about the way to go to get these permissions > in a non-artificial scenario. But I can reproduce it like this: > > - The file xxx has a primary group different from the group which has > permissions, e.g.: > > owner: foo > pgroup: foo_group > > acl: 1 entry > bar_group: full control > > - ls -l xxx > ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx > > - $ chmod g-w xxx The chmod, if you try to run it, never succeeds. That's the crux of this setup, anything will always have just rwx for the group via ACL and you can't change that. > So, what's going on here and how do we really fix it? It *might* be > prudent to drop any efforts to create DENY ACEs to reflect the POSIX > perms. That results in the documented permission gap between POSIX and > Windows permissions, though. There's just no way to express all possible > POSIX permissions using Windows ALLOW ACEs only. There aren't any deny ACL, you just don't get the right to play with the permissions to start with. FOr Windows it doesn't matter that the owner hasn't got any access rights as long as she's in a group that has. POSIX doesn't even look at the group/ACL if it the owner bits are cleared. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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 |