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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=nH+SPFvT4ozTVjE9fWBbDmKVau3foI/dUfiAX+Jn0iD
	HxWxl/NoYM1l+7dn+kHcjurECTnfi851LDuCTZzwmpXQDtjROU0j8/PFrp1Rg9ZV
	e3FmkIVy5898/eoTqELtdTkRSzV+zaS9slSsxlCciOr50mFpjvCNP9xEhjiR1Jqo
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=rtX/G8Pqcb2fO03rSpP5GqayxUc=; b=esaI6kHutDWzmumL2
	80iGHxXCqZDjeLdltnaLpkouFJ43A0Eb5ZI4zKzgAwbvaxxItCM50ejhs663qOaS
	J28P89fa1u8wFL+hS1rRyXoHzLETeG6ygwi9T8xQd2hSabvOCZJ/oNbiuqVM8l23
	PJcdlHmvU4ay3kJBupAkRIqKWk=
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=3.1 required=5.0 tests=AWL,BAYES_20,FOREIGN_BODY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2
X-HELO:	mout.kundenserver.de
Message-ID:	<54DA5633.7090900@towo.net>
Date:	Tue, 10 Feb 2015 20:04:19 +0100
From:	Thomas Wolff <towo AT towo DOT net>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: group permissions
References:	<54D7EB4E DOT 6020105 AT towo DOT net> <20150209091445 DOT GA10457 AT calimero DOT vinschen DOT de> <54D91687 DOT 8090301 AT towo DOT net> <20150210092122 DOT GA15989 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20150210092122.GA15989@calimero.vinschen.de>
X-TagToolbar-Keys:	D20150210200418928
X-UI-Out-Filterresults:	notjunk:1;
X-IsSubscribed:	yes

Am 10.02.2015 um 10:21 schrieb Corinna Vinschen:
> ...
> Here's the problem:  Windows doesn't support an ACL_MASK entry, nor
> anything even remotely resembling it.
>
> What does that mean for us?
>
> When reading permissions from a Windows ACL, the ACL_MASK entry can only
> be computed from the given values.  The ACL_MASK entry can not be written.
>
> If Cygwin would like to emulate writing an ACL_MASK entry and the Linux
> kernel way of writing an ACL_MASK via chmod(2), there would be two ways
> to implement that:
>
> o One way would be to fake the mask value by adding an ACL entry with an
>    otherwise unused SID.  Cygwin already uses an ACE with the NULL SID
>    (S-1-0-0) to emulate S_ISUID, S_ISGID, S_ISVTX, the latter of which
>    actually works, the first two just being fake.  We could use the NULL
>    SID for ACL_MASK as well.
>
>    However, this fake is somewhat dangerous.  The current implementation
>    computes the mask value and adds it to the group permissions, because
>    that reflects reality much better than the old implementation.  The
>    permissions on the files *are* open to other users and thus a
>    security- conscious, but not ACL-aware application like SSH should
>    now.  If we fake ACL_MASK as described above, we're not better off
>    than with the old implementation.  The NULL SID would just fake tight
>    permissions, in reality the permissions are still open.
>
> o The other way to emulate writing an ACL_MASK entry would be to drop
>    permissions from all groups and secondary users so they match the
>    desired mask value.  This is secure, but in contrast to the other
>    solution it would change the secondary permissions permanently.
>    Changing the mask back would not change the permissions of the
>    secondary ACL entries back.
>
> And a third one, which just occured to me after writing the above:
>
> o Cygwin could emulate the mask by adding an Access-denied ACE for the
>    authenticated user SID (S-1-5-11) right after the primary group entry.
>    The permission in this ACE are the x'or value of the permissions
>    given in the mask.  Such an ACL would basically look like this:
>
>      primary user   rw-
>      primary group  r--
>      S-1-5-11       -wx deny
>      some-group1    rwx
>      some-user2     rw-
>      Everyone       r--
>
>    The effect would be almost (bit not quite exactly) as if a mask
>    value of 'r--' is given.  Since the other groups and users are
>    authenticated users, this would effectively disallow them the
>    access denied by our "authenticated user mask".
>
>    If the authenticated user SID doesn't work as desired, the fallback
>    would be Users (S-1-5-32-545).
>
>
> I'm open to discuss this further.  It needs implementing, of course.
Thanks for the extensive explanation. Considering that others have 
problems with the apparent “chmod does not work anymore” as well, I 
would vote even for a “hacked” change.
My preference at this time would be option 2 because it’s easier to 
understand than option 3 (and who cares to preserve entries not set by 
cygwin but imposed by Windows default ACLs) but maybe option 3 would be 
more “correct”.

Another (or additional) option could be to (optionally?) ignore Windows 
directory defaults when creating a new file (and distinguish them from 
other default entries that may have been added explicitly...).

As a combined approach (with your option 2), chmod could modify only 
those hidden entries that typically come from Windows defaults (or those 
that are parent directory defaults at the time of the chmod),
so chmod would “work again” at least for those users that don’t touch 
ACLs themselves.

Most of this doesn’t resolve the issues with applications that choke on 
more permissive group permissions than expected (which seems to be the 
issues in other threads).
To mitigate this, I would suggest to ignore the (Windows) system entries 
(group:SYSTEM, group:Authenticated Users, group:root ?) for the 
composition of the visible group flags.

------
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com


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

- Raw text -