From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44500 invoked by alias); 20 Apr 2015 09:18:11 -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 44487 invoked by uid 89); 20 Apr 2015 09:18:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Apr 2015 09:18:05 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5AD22A80951; Mon, 20 Apr 2015 11:18:02 +0200 (CEST) Date: Mon, 20 Apr 2015 09:18:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 Message-ID: <20150420091802.GN3657@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <5531F272.4070803@gmail.com> <20150418100612.GK3657@calimero.vinschen.de> <5534152B.3050908@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ZSpXV6RUUo6PuQK" Content-Disposition: inline In-Reply-To: <5534152B.3050908@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00456.txt.bz2 --0ZSpXV6RUUo6PuQK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4520 On Apr 19 13:50, random user wrote: > >>> 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? >=20 > 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. Yes, but Linux doesn't have to maintain native Windows tools. I would rather not have these default entries but they are there for ages and they seem to be useful to people. So what's the point? On Linux the "default-default" entries are not changes with chmod, and on Cygwin they aren't either. And that's the right thing to do on both systems. A chmod on a dir never influences the mask of files created in that directory. > >> Any suggestions? Always applying umask, no matter what? >=20 > 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.) >=20 > 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: http://linux.die.net/man/5/acl explains it: If a default ACL is associated with a directory, the mode parameter to the functions creating file objects and the default ACL of the directory are used to determine the ACL of the new object: 1. The new object inherits the default ACL of the containing directory as its access ACL. 2. The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter. If no default ACL is associated with a directory, the mode parameter to the functions creating file objects and the file creation mask (see umask(2)) are used to determine the ACL of the new object: 1. The new object is assigned an access ACL containing entries of tag types ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER. The permissions of these entries are set to the permissions specified by the file cre=E2= =80=90 ation mask. 2. The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter. Bottom line: Either the parent has default perms, or umask is applied. > 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. > [...] Sorry, but that sounds much too complicated for my taste. Let me simplify this a bit. I'm only concerned about the behaviour of the underlying functions in Cygwin for this, and it should be *simple* so that the logic isn't too confusing and still understood in a year. From the new code's perspective there are two kinds of ACLs, old or native Windows ones, and new ones. Problem: We need those three inheritable ACEs for native tools, When creating a new file, it will inherit these ACEs. On each file creation, Cygwin checks the ACL and pulls it straight again. We would like to allow file creation to recognize the created ACL as being a "standard" ACL and apply umask. For new-style ACLs it looks easy: We could define an extra bit in the inheritable DENY NULL ACE. if the bit is set (after mkdir) Cygwin applies umask for files created within. If not (after setfacl) it doesn't. That leaves the existing, Cygwin-created ACLs. I think we should compromise here. If the incoming, inherited ACL contains the three entries for user, group, and other, it's with very high probability inherited from a Cygwin created directory. If the inherited ACL contains nothing else, we're going to apply umask, otherwise we don't. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --0ZSpXV6RUUo6PuQK Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVNMRKAAoJEPU2Bp2uRE+g4oQP/RNfrsNGOjG7AM8ZPRiVWKcV /xH4ITjpgYaa+QYX9eQaXQR2DMpqfyOxYoBIZfvruf9vhpKW+D3sx/0l6KaUWwd/ I1uVlGeBeyyyFlP6jrpkKaFxGDXk6wGBEM64Nh65i/iFk7rUXm83UP8kb+P+WDol zZwKM12A3xxW+kGsTrMkufPz48Z8pMGRz0GSj8rPUGkF2qCtXp6zfcVR1vOj0C2r dr7MDZ7TSvF8C8deilb1NMeUebDU6V+/mIlApg9wSXjOvbGkl9pV6IRcEMfvmeQv E9j+Pfnio7VgCjffmdy3NhmTzAAWu+GFR2QsUnPjZORZz9hvY/iNcvr90VzfLPfm OoQ3ccJcV2IQWfzWN6NrMDk9UxWzlhWyB0aJsOwGZMMV1nZZLG6ap4LZ0IYWwtaP 4WVqObACJDup4vvW0URqbT4o7L2GviIHvO6CYiABODuMT3VW+4+/6YVoKiYauDvP FzOX27yRpcLcSJtwsVv1uBoNmUzUj3DqdlyOKY6gcytYoowN7yek4Pj62B7aghDF fkmLZlrzxCavFkWlDZzf8nG0W8AtBEpr+qAXEwAxmJRXQnckUKa/5/VWTssQGXnZ ENU+CzKwfX4+F3Htdhzq7AHzmd4vtg0SQZ6Oo6+XXpsfcElN8SEapd8vH85rzYgI XMr337aHWD4iAlkE6vo4 =KxhQ -----END PGP SIGNATURE----- --0ZSpXV6RUUo6PuQK--