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=Hoev77MqoYWtouwiN4RDHGcjaUSXHY6HwvTNzZIYF/P
	KiYaV3sVsdOK5IierW0ntOikymQ4yFx/t6kp/X7ema8J/AHTOPfq+sxu8XeZ3v5Z
	7G+Tug+UthoSVT0LKhhX/t0zDYGrcUDSwcshxTGFtnI3pF1LTFOeaArvt/4qSztM
	=
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=/eGFJGcKV0tPNzhPM1RqoeUNCi0=; b=GcGzzDIfO3YdwTvwN
	3KUtnb7fo32tfiFZJVIZtwqhSJhb9e6y7KkxwN6C+SF7iaH3rPgvlHsVi3Y/Gaev
	vDmXZgKKr1NPelM1N3tte00amv3WvdP60of/JUuX5hzj/Ii938F0Cii/NLACP5sF
	2K/0qch/5r9YCWWeJ7WbjhT3u4=
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.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2
X-HELO:	mail-pa0-f42.google.com
X-Received:	by 10.70.126.225 with SMTP id nb1mr36125458pdb.40.1425171874013; Sat, 28 Feb 2015 17:04:34 -0800 (PST)
Message-ID:	<54F26595.3030400@gmail.com>
Date:	Sat, 28 Feb 2015 17:04:21 -0800
From:	random user <cnpxzsdwle4m0dkt AT gmail DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Too Many Permissions Stripped In 1.7.35?
References:	<54F00036 DOT 8050509 AT gmail DOT com> <54F233D8 DOT 1040503 AT gmail DOT com>
In-Reply-To:	<54F233D8.1040503@gmail.com>
Note-from-DJ:	This may be spam

Re the user SID != group SID, chmod -x case: Thanks, sorry to have
wasted your time. It does seem the same on Linux, and chmod ug-x does
appear to work correctly. My bad.

Re the user SID = group SID case:

I'm not offhand spotting how to use chmod to create the ACL your "They
do:" example displays. With 1.7.35(0.286/5/3) 2015-02-27 17:16,
Everyone permissions don't seem to leak into the group mode for the
file owner user SID != group SID case. After a "chmod 607 x" where
file owner user SID != group SID, I see in ls
  -rw----rwx 1 XXX YYY 0 Feb 28 16:28 x

For the user SID = group SID case, further testing seems to show that
what gets presented now as the group mode is actually the bitand of
the user and Everyone permissions. Is that correct?

(I had interpreted from the announcement email that group mode bits
would show as = Everyone mode bits.)

If that is correct, and (as it does appear in testing) a DENY ACE is
created denying user=group any additional privileges granted only to
Everyone, guess this doesn't bother me too much, but still it doesn't
seem best.

From an actual security point-of-view, seems either representation is
reasonably accurate, as all the actual privileges granted are always
shown in the user permission mode and there can't possibly be any
"members of the group" other than the user for the group SID = user
SID case. Is that thinking correct?

But the current approach seems to lead to inconsistencies at the
appearance level. Everyone bits don't appear to fold into the group
mode at all if user SID != group SID, as seen above. So there is now a
difference in impact on the visible group mode when doing a chmod
o+<whatever> when group SID = user SID than when !=, tho no actual
difference in security impact.

There also seems an inconsistency introduced between the apparent
group mode as it shows in ls and the group mask. Am I right in
thinking that in Posix these are meant to be the same?

rm x
umask 077
touch x
chgrp <same as user SID> x
setfacl -m 'g:SYSTEM:r--' x
ls -al x
getfacl x
chmod o+w x
ls -al x
getfacl x

And looking forward to the possibility of a more Posix-y mask in
future, I think it'd be wrong to ever add bits to the group mask upon
a chmod o+<whatever>. If there are other group ACEs present, with the
mask disabling some of their permissions due to a previous chmod
g-<whatever>, I wouldn't think a chmod o+<whatever> should ever itself
re-enable any of those permissions, right?

Thus my thinking that it'd be preferable for the file owner user SID =
file primary group SID case that the primary group permissions should
always show as 0, regardless of the Everyone permissions.

Thanks again for considering my thoughts. I don't mean to be too pushy
here at all, or even to be claiming to be very knowledgeable on
this. I respect, having seen Cygwin's evolution, that you clearly have
good judgement and put a lot of care into what you implement, and have
likely thought through these issues much more than I. (And I half
expect you'll respond with some quite correct trivial explanation of
why I'm "all wet"; if so, in advance and again, sorry for wasting your
time.)


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