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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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+ 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 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+. If there are other group ACEs present, with the mask disabling some of their permissions due to a previous chmod g-, I wouldn't think a chmod o+ 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