From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 571 invoked by alias); 19 Apr 2015 20:50:58 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 559 invoked by uid 89); 19 Apr 2015 20:50:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pa0-f42.google.com Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com) (209.85.220.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 19 Apr 2015 20:50:56 +0000 Received: by paboj16 with SMTP id oj16so186050465pab.0 for ; Sun, 19 Apr 2015 13:50:54 -0700 (PDT) X-Received: by 10.70.41.81 with SMTP id d17mr23041629pdl.16.1429476654567; Sun, 19 Apr 2015 13:50:54 -0700 (PDT) Received: from [209.204.163.19] (209-204-163-19.vpn.sonic.net. [209.204.163.19]) by mx.google.com with ESMTPSA id ks1sm15978998pbc.58.2015.04.19.13.50.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 13:50:53 -0700 (PDT) Message-ID: <5534152B.3050908@gmail.com> Date: Sun, 19 Apr 2015 20:50:00 -0000 From: random user User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 References: <5531F272.4070803@gmail.com> <20150418100612.GK3657@calimero.vinschen.de> In-Reply-To: <20150418100612.GK3657@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00452.txt.bz2 Hmm... Seems my Item 1 and Item 2 are more related in your design thinking than I had realized. >>> "extended ACLs" (is that the proper phrasing?), >> (default ACL entries in POSIX speak, inheritable ACEs in Windows) I'm looking for the term that would distinguish whether on Linux ls shows a '+' and getfacl shows a mask: line, and controls whether umask is ignored or respected and how chmod behaves -- which seems on Linux whether any ACL entry other than those needed to represent the basic mode are present. I'll stick with "extended ACLs" for this below; Google seems to show many hits with this intended meaning on that phrase. >>> I note that chmod doesn't keep these to-be-inherited entries in sync with the directory's mode; >>Yep. Did you check against Linux behaviour? The difference to my eye is that on Linux there is no such to-be-inherited CREATOR OWNER ACL entry created implicitly by mkdir. If there is one existing, it's because it was created explicitly with setfacl, so seems more the user's responsibility to maintain. >> Any suggestions? Always applying umask, no matter what? Please, no. That would create a behavior pattern quite different than Linux's. I don't myself like some aspects of the Linux/Posix behavior, but, at least to me, having Cygwin behave compatibly so that code/scripts behave the same on Cygwin as on Linux is way more important. (Please read this paragraph also as my reply to you re the Item 1 topic.) Tho, to be precise: I think I am seeing on Linux that umask is always applied, just it is applied differently depending on whether any default ACL entries are present on the parent directory: a1) on Linux, if there are any default ACL entries on the parent directory, umask is applied to these. Execute perms are then also dropped when creating a new non-directory. a2) on Linux, if there are no default ACL entries on the parent directory, umask is applied to 0777. Execute perms are then also dropped when creating a new non-directory. b) in current/older Cygwin releases, umask is applied to 0777. Execute perms are then also dropped when creating a new non-directory. The result is then combined with any to-be-inherited ACL entries from the parent directory. Does that all seem correct? As to a suggestion.... OK, I'll toss out a strawman. Maybe it'll be food for thought, parts of it useful, even if you don't like/choose the entire approach. Please expect/forgive some possible glitches as this isn't my direct area of expertise. Inputs/goals: a) The above re umask behavior. Also the two distinct Posix behaviors of chmod, it either impacting the primary group "permanently", or impacting only the mask. [Q: Are these the only differences between "simple" and "extended ACLs" behavior, as far as actions that create ACLs/make changes go?] b) I note that on Linux it still seems to take explicit user action to end up with "extended ACLs" behavior. At least in my experiences so far, new installs aren't typically set up in such a way that users would see any such cases, unless/until they create such themselves, most likely only via explicit use of setfacl. So I'm interpreting that "extended ACLs" behavior isn't something that Linux is trying to push people into using, it's an available option but not seeming preferred/forced. Build and install scripts for the various packages are likely not expecting "extended ACLs" behavior, and so far it wouldn't seem likely that there'd be a major round of rewriting of them all. Thus I'm thinking it's likely not so desirable that Cygwin would consider existing cases to be ones that get "extended ACLs" behavior. Existing cases would seem better "grandfathered", continuing with closer to existing non-"extended ACLs" behavior re umask and chmod. c) The desire of various folk to have some ACL entries always present for non-Cygwin maintenance/backup programs. And as a subpart of this, a desire by various folk that the 'visible' mode bits (what's seen in ls and by programs checking for 'tight' permissions) would ignore these, even if that means that that these Cygwin programs aren't seeing all the actual permissions granted on the dirs/files. (I suspect here is where contrary opinions might exist. Those more wanting to use Cygwin to manage Windows, rather than as a Posix-compatible environment despite of Windows, would likely prefer that all actual permissions are visible.) d) The desire to have some to-be-inherited/default ACL present on a directory for non-Cygwin programs to be able to create files in it sanely. e) A desire to provide good Posix setfacl behavior as new functionality, but to avoid hassling people who aren't really looking for that functionality, want their current environments to keep working mostly as-is. (Not sure if the upwards compatibility concen is generally as topmost in Cygwin design thinking/planning as I'd think it ought to be.) Possible flexibility/leverage point vs the current design: >> Yes, that's a problem. The underlying problem is that you can't distinguish inheritable ACEs created by Cygwin just for the sake of Windows applications from inheritable ACEs created explicitely and willingly to have the same behaviour for Cygwin apps. They are identical to the bit. But it seems your new representation for ACLs would give you the ability to treat ACL entries created by new-version setfacl differently from any Windows-created or old-Cygwin created ones. The presence of your new NULL SID entry, plus then having a DENY present preceding an allow ACL entry, would seem able to mark the difference. I've not encountered DENY ACL entries used much on files/dirs in Windows, prior to your new design. Am I right in thinking they are not at all common, that we can perhaps design with an assumption that folks wouldn't likely be needing DENYs present on their for-non-Cygwin ACL entries, (c) above? (Clearly it'd be a possibility that a DENY might exist, but either error trap, refusing to create "extended ACLs" if one does, or just document that there might be surprising behavior. The choice of whether to best include a NULL SID now always or only if some category (2) items as discussed below are present might depend on how you wanted to deal with this.) Thus: What if we logically think of four distinct sets of ACL entries: 1) ACL entries present to represent the simple mode bits, or in Posix ACL terms the user::, group::, and other: ones. I'm not sure if these are CREATOR OWNER / CREATOR GROUP for the ACL entries representing the current file/directories' own, or are the actual user and group SIDs (icacls seems to show them as this latter, but maybe it's just folded in the user/group names for sake of display?), but the discussion re u:: and u:username: being able to coexist suggests one way or another you can determine which are u::, g::, which are u::username: or g:usersgroup:, yes? 2) Posix-behaved "extended ACLs" entries. These would only be ones created by new-version setfacl. 3) "Windows artifacts" ACL entries. Any currently-existing ACL entry that's not category (1) or (4) would be treated as one of these, even if it had been created by old-version Cygwin. I would see that as a positive for easier migration. Any new ACL entry added with icacls or Windows GUI would be treated as one of these, unless someone puts effort into creating a DENY entry as well. (How well icacls and Windows GUI would behave when used to modify your new form of ACL representation is something I haven't explored tho.) 4) A base set of to-be-inherited ACL entries present on directories for sake of non-Cygwin programs creating files in them. These would be placed by mkdir (as currently), but would also be placed when setfacl -k/-b removed default ACLs. Use of setfacl explicitly to create any default ACL (which should then be category (2)) should best implicitly remove all these. It's likely a separable topic, but my own suggestion would be to no longer have these dependent on the directory's own mode, but rather on new mkdir or setfacl use that would add them, just always set to CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA) Everyone:(OI)(CI)(IO)(Rc,S,RA) This would be to avoid my concern about these not tracking a later chmod, and also that giving CREATOR OWNER less than (F) doesn't work so well for non-Cygwin programs. As a possible representation: Category (2) cases would always have a preceding DENY. Any non-category (1) entries without a preceding DENY would be treated as categories (3) or (4). The primary group would have a DENY present if needed to represent a mask, which would only occur if some category (2) case is also present. Category (1) and (2) ACL entries should follow Posix behavior. On new file/directory creation, category (4) ACL entries of the parent directory would be ignored when Cygwin creates a new file/directory. If any category (2) default ACL entries are present, then umask behavior (a1) would apply, else (a2). Then any category (3) ACL entries would be folded in, remaining category (3) on the new file/directory. For a new directory, if there are no category (2) default ACL entries, category (4) entries would be added for those of CREATOR OWNER, CREATOR GROUP, Everyone that didn't have a category (3) to-be-inherited already applied. Rules for chmod would depend on how you want to deal with category (3) items. In 1.7.35 chmod is impacting these, which if I've understood right has gotten some complaint on the email list. Possible choices: a) chmod would impact category (3) entries. If there are any category (2) present, then category (3) would be converted to category (2) if chmod 'g-' creates non-empty masks. Else, following 1.7.35's behavior, these would get modified similarly to the primary group. Special casing of SYSTEM and ADMINISTRATOR would remain an orthogonal design choice. b) chmod would simply ignore category (3) entries. If going with (b), then the question would be how to deal with chmod then not having impact on the visible mode bits display if the permissions remaining on category (3) ACL entries show through. A choice might be to not include category (3) entries in the visible mode bits. If doing that, I think I'd suggest getfacl might have an option to display categories (3) and (4) or not, with a # "comment" as used by #effective: to not they are non-Posix-behaved. Maybe whatever 'ls' uses to determine if to show a '+' would also ignore category (3) and (4) entries presence. I'm not myself caring much anymore about category (3) cases, either approach would be fine by me. I've already cleaned my own directory trees to not have any category (3)'s. But it does seem these are a common topic raised on the email list. To me, having category (3) permissions not reflected in ls/find/access()/etc. behavior wouldn't bother me too much, using icacls isn't so hard. I'd tend to prefer that the same commands would have the same visual behavior on Cygwin as on Linux, even if Cygwin wasn't then reflecting "Windows artifacts" including even permission grants. However, I expect others may differ on that. I would suggest category (4) behavior is important tho. Having mkdir itself put the directory into "extended ACLs" mode for new file creation in it seems a poor choice, incompatible with Linux behavior. Having mkdir or setfacl (including -b/-k) create cases with no to-be-inherited ACLs seems asking for trouble in the use of non-Cygwin programs. >> Do you mean the POSIX API? Likely I do, I think that's what tar is looking for. Regarding my earlier Item 3: Glad it helped you spot a bug. I've played further with Linux, now think I understand, no longer have conceptual concerns. Thanks for considering these thoughts. -- 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