From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32970 invoked by alias); 24 Apr 2015 02:14:26 -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 32957 invoked by uid 89); 24 Apr 2015 02:14:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 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-f47.google.com Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 24 Apr 2015 02:14:22 +0000 Received: by pacwv17 with SMTP id wv17so12434416pac.0 for ; Thu, 23 Apr 2015 19:14:20 -0700 (PDT) X-Received: by 10.68.139.225 with SMTP id rb1mr10397802pbb.93.1429841660403; Thu, 23 Apr 2015 19:14:20 -0700 (PDT) Received: from [209.204.163.16] (209-204-163-16.vpn.sonic.net. [209.204.163.16]) by mx.google.com with ESMTPSA id xt9sm9315322pbc.14.2015.04.23.19.14.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 19:14:19 -0700 (PDT) Message-ID: <5539A6F3.4090107@gmail.com> Date: Fri, 24 Apr 2015 02:14: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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 References: <20150421121559.GY3657@calimero.vinschen.de> <87a8y15rie.fsf@Rainer.invalid> <20150422090440.GB3657@calimero.vinschen.de> <877ft480zp.fsf@Rainer.invalid> <20150423083446.GG3657@calimero.vinschen.de> <877ft2ptuj.fsf@Rainer.invalid> <20150423194908.GA13598@calimero.vinschen.de> In-Reply-To: <20150423194908.GA13598@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00570.txt.bz2 Let me take a try on Achim's case with/refining the "alternative idea"; this seems one of the kinds of cases that it is intended to help. (Corinna, I hope at least some of the ideas here prove helpful to you, and my posting this isn't (too) annoying. Again, please expect/forgive glitches as I'm not an expert on the internals of the Cygwin library nor are file ACLs directly my area of expertise. I've included a lot of detail to try to see for myself if the pieces would seem to all fit together properly, but to whatever extent those details don't match possible reality, please try to see the abstract idea/goal of supporting coexisting purely Windows-behaved and purely Posix-behaved ACL entries.) (Achim, I would be interested in hearing how well this approach would seem to serve your needs/desires; there's a summary of the resulting behavior for this case in the last main paragraph below.) >> On the source tree the file owner (a domain user) doesn't have any rights, access is granted by one of the share groups (separately for read-only and modify access) and the filer admin group (modify access plus a few more permissions). None of the share groups have permission to modify the DACL and everything gets inherited from the root node of the share (it's a NetApp, but I don't think that factors into that problem other than being the standard setup on these files apparently). Here the "share group"(s) and "filer admin" seem examples of ACL entries that are intended to behave following Windows, not Posix, behavior. I would expect the most desired behavior would be that they would be inherited onto any newly-created files in those directories following Windows' behavior, without at all impacting Posix behavior such as whether (creation mode & ~umask) should be applied. That they would best not be impacted at all by chmod, or by setfacl creating a Posix mask. And that Cygwin/GNU tools such as rsync, also cp, tar, etc., would best not carry these non-Posix-behaved/Windows-purposed ACL entries from one directory subtree to another, but rather carry across only Posix-behaved permission mode and "extended ACLs" plus fold in whatever non-Posix to-be-inherited entries are present on the target directory. To achieve that, in this "alternative idea" the correct Posix mode for this particular (extreme) case described by Achim would be --------- = 0000. Similarly, getfacl would not show the "share group"(s), "filer admin", or SYSTEM, ADMINISTRATORS, USERS, AUTHENTICATED USERS, etc. ACL entries in this example at all (none of these are the primary group, none of these are created with new-version setfacl). The impacts of these non-Posix-behaved ACL entries would be visible via Cygwin/Posix APIs only the same as Linux shows impacts of root's "magic" rights. I would expect the lack of visibility of all granted permissions to be an aspect some folks won't like about this "alternative idea" model, but it seems necessary for ~/.ssh and similar cases to behave as multiple people seem to be requesting, for chmod to have the visible effects that it should without actually impacting these non-Posix-behaved ACL entries, and for (creation mode & ~umask) to be applied or not based on whether there are any Posix-"extended ACLs" group/default entries but not impacted by non-Posix-behaved ACL entries. icacls would be the program to use if wanting to see non-Posix-behaved ACL entries, tho perhaps getfacl could have an option with some special-case code involved to be able to display these, ideally marked as '#non-Posix' or some such. At the Windows ACL level, this case does point out the need to be quite careful about ordering. Assuming Windows stops on the first match it finds for an ACL entry the current user token and desired kind of access matches, it would seem the non-Posix-behaved ACL entries need merely to be kept earlier in the ACL than any Posix-masked entries to avoid being impacted by the Posix-mask DENYs. I've also thought through a little more re non-Posix-behaved DENY cases; I now think they can coexist with Posix-behaved masking if we locate the NULL SID carefully and choose (as I think is likely what'd be most wanted by the Windows administrator) that any non-Posix-behaved DENY should have priority over any Posix-behaved permission grant. Thus I'm thinking the best ACL ordering would be non-Posix-behaved ACL entries NULL SID owner primary group other Posix-behaved users/groups (all referred to below as "groups") others/Everyone To-be-inherited markings/entries should be kept in/following the same active-for-this-file case/SID above, in particular, all to-be-inherited-as-non-Posix-behaved ACL entries would precede the NULL SID marker, Posix-behaved default entries after. The Posix-behaved group entries should have a DENY preceding their ALLOW if and only if by Posix rules a mask should exist. The value of the mask seems just the inverse of what the DENYs deny, which it seems can be written the same for all the Posix-behaved groups without being dependent on what permissions that group's ALLOW would have. If any DENY are present for Posix-behaved groups, they would all be expected to represent the same one mask value, so there would seem no importance to the ordering amongst Posix-behaved groups other than that the related DENY precede each ALLOW. Representing the mask within the NULL SID entry also as Corinna wrote about earlier would seem not necessary, but not harmful. When reading a Windows ACL, the Cygwin library would start off processing the types of ACL entries it has historically treated as owner, primary group, and others, but simply ignoring all other entries unless/until it sees the NULL SID marker. At that point it would process all the remainder, treating them as Posix-behaved. When writing a Windows ACL, Cygwin would want to start by copying/keeping existing ACL entries the file/directory has, but filtering out any it considers owner/primary group/others, until it hits the end of the ACL or the NULL SID entry. At that which point, stop copying what previously exists and instead write values per the now-desired Posix mode and Posix-behaved set of ACL entries. Whether the copying/keeping of early entries should remove any non-Posix-behaved ACL entries with the same SIDs as Posix-behaved ones that are to be written seems a choice that could be made in either direction. This would all seem to work pretty well assuming the non-Posix-behaved ACL entries are always created on a directory tree before Cygwin starts writing into it. I am uncomfortable tho about what would happen should someone apply icacls or Windows GUI changes *after* Cygwin has created an ACL with Posix-behaved additional groups or defaults. I'd expect problems, especially with the Windows GUI if I recall correctly that it reorders ACL entries. But even using icacls to add a new non-Posix-behaved entry would appear to be difficult, as it doesn't seem to have any "put this first" kind of option that I spot, rather only wants to keep all ALLOWs after all DENYs. Cygwin might provide some special option/code in setfacl or some distinct program to help maintenance, but a Windows admin might just use the Windows tools regardless, causing effective corruption. To ease this concern, the NULL SID should be written preceding the Posix-behaved items if and only if there are any Posix-behaved added groups, Posix-behaved defaults, or Posix mask present. No NULL SID should be written if only non-Posix-behaved ACL entries plus simple owner/primary group/others Posix mode permissions need to be represented. This way icacls and Windows GUI would remain safe for use modifying any file/directory that has not had explicit new-version setfacl activity; any new ACL entries they'd create would be properly treated as non-Posix-behaved. Reordering might mess up the owner/primary group/others ordering necessary for precise Posix semantics, but that would seem an already existing problem and for the most typical cases of naturally decreasing rights not a real concern. Summarizing for Achim's particular case, the behavior would be simply that the target new files/directories would get only ACL entries as defined by the non-Posix-behaved to-be-inherited ACL entries of their target parent directory, followed by an ALLOW of (Rc,S,RA) to each of file owner, primary group, and Everyone, representing the 0000 Posix mode (assuming rsync is creating target files/dirs with, or after creation chmods them to, the 0000 Posix mode matching the source; else (creation mode & ~umask) would be represented). No other ACL entries from the source files would be copied over to the targets. For this case, no NULL SID nor any DENYs would be created. Thanks again 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