From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109525 invoked by alias); 18 Apr 2015 10:06:17 -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 109515 invoked by uid 89); 18 Apr 2015 10:06:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,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; Sat, 18 Apr 2015 10:06:15 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 8B89BA8084B; Sat, 18 Apr 2015 12:06:12 +0200 (CEST) Date: Sat, 18 Apr 2015 10:06:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 Message-ID: <20150418100612.GK3657@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <5531F272.4070803@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Edk6HoYKP7RsK9ib" Content-Disposition: inline In-Reply-To: <5531F272.4070803@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00435.txt.bz2 --Edk6HoYKP7RsK9ib Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 6741 Hi random user (at least a first name would be nice, you know my first name as well, isn't it?), On Apr 17 22:58, random user wrote: > Hi again, Corinna. >=20 > I appreciate these recent changes, the more complete Posix ACL support > looks beneficial for sharing/syncing files between Cygwin and Linux > machines, and for more compatible scripting. >=20 > But I've noticed a few possibly-concerning items: >=20 > Item 1: >=20 > >> - I introduced a change in chmod behaviour which is not exactly in > line with POSIX 1003.1e draft 17: >=20 > This change looks to me to be somewhat dangerous. I'm concerned it > may lead to granting privileges one doesn't expect to have granted. > And scripts leveraging this would behave noticeably differently on > Cygwin than they do on Linux, leading to extra time to debug/recode. >=20 > A simplistic example use case: Ok, I understand the concern here, but I really didn't do that change out of the blue. Maybe I'm just dumb, but I puzzled myself with this behaviour a couple of times. I think that this specific behaviour defined in draft 17 is surprising for the end user. The difference between Linux and Cygwin is that Cygwin users have *lots* of ACLs with default permissions for secondary users by default while on Linux this feature is used in limited circumstances. So without this change, what Cygwin users get is something like this by default: $ touch foo $ chmod g+w foo [switch to another user, member in the same group] $ echo bar >> foo echo: Permission denied A Linux user will never encounter this behaviour in the default case. This is what concerns me a lot and what triggered this change. I'm willing to rethink this change, but for the time being I'd like to keep it this way and test it with a bigger user base (not only the few testers). > Item 2: >=20 > I'm having troubles figuring out how to create a directory that plays > well both for providing old-style umask behavior and as a holder of > files created by non-Cygwin Windows apps. Yeah, I know what you mean. Here's another example of following 1003.1e to the letter while at the same time trying to accommodate native Windows applications... > (The actual permissions in these seem to vary based on the umask > setting and any inherited ACLs at time of directory creation.) > This seems existing behavior in Cygwin, still present in this > test drop. (This is very old code. Windows applications rely on inherited ACLs, so creating Cygwin folders POSIX style, without inhertable ACEs, will result in weird permission settings for files created with native tools) > What I seem to be seeing is that with these present, this test drop > appears to now be treating the directory as having "extended ACLs" (is > that the proper phrasing?), (default ACL entries in POSIX speak, inheritable ACEs in Windows) > and so now will use these default: ACL > entries to create the permissions for a newly-created-by-Cygwin-app > file rather than using umask. ...the 1003.1e part being to apply the umask only if the file does not come with inherited permissions. Due to the default ACEs created by default, all files will have inherited permissions and thus umask is seldomly applied. 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. So it's not clear in this scenario when to apply umask. From the 1003.1e perspective the code is doing the right thing, but the result may, again, be surprising. Any suggestions? Always applying umask, no matter what? > I can use 'setfacl -k .' to remove these, but then if I try to write a > file into the directory using a non-Cygwin program I end up with a > rather strange set of ACLs on it. Typically you get the default DACL from your user token: $USER rwx SYSTEM rwx Admins rwx > I suspect the desire to allow non-Cygwin apps to > sanely create files in a Cygwin-created directory is likely the reason > that mkdir is creating these ACL entries. As outlined above. > Would it maybe make sense for 'setfacl -k' to keep/recreate the same > base set of to-be-inherited ACLs that mkdir does, and for the > determination of whether to use umask vs. the default: ACLs to ignore > these? Maybe for better cosmetics, for getfacl to not show these, nor > ls to show these cases only as causing a '+' to appear, so that a > newly-created directory with no ACLs inherited from above would appear > both visually and behaviorally as not using "extended ACLs"? No. I really don't think so. Again, the point is that you can't inherited ACEs for Windows-only from explicit default ACL entries created by a user. Second guessing here and not showing entries will even be more surprising. > 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? > they seem stuck at their create-time values > unless changed explicitly with icacls. Why icacls? Just use setfacl. > (And am I right that these > can't be easily changed with setfacl, since the SIDs involved don't > have Cygwin user/group mappings?) Hmm, that sounds like you never actually tried it... > Item 3: >=20 > It seems to create rather messy/redundant ACLs if one tries to use > setfacl to adjust the owning user's privileges explicitly by user > name. As on Linux: $ touch foo $ getfacl foo # file: foo # owner: corinna # group: vinschen user::rw- group::--- other::--- $ setfacl -m u:corinna:r-- foo $ getfacl foo # file: foo # owner: corinna # group: vinschen user::rw- user:corinna:r-- group::--- mask::r-- other::--- I found that a chmod u-w then results in permission denied messages when tring to change the permissions back, though. That's clearly a bug. > Item 4: >=20 > Just a question (tho if 'no', then a 'wish list' vote for some > "soonish" future release): Is this coming release likely to provide > the right APIs for ACL handling that we can then build tar enabled to > save/restore ACLs? I don't understand the question. Cygwin provides the low level ACL API from original Solaris. Keep in mind that the orignal code in Cygwin is older than the Linux implementation. Do you mean the POSIX API? If so, I'd be glad if somebody would take a stab at implementing the POSIX API in terms of the underlying Solaris API. Really, *really* glad. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --Edk6HoYKP7RsK9ib Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVMiyUAAoJEPU2Bp2uRE+gxLQP/idGWX/zCBIAVnsx8RoW2jA6 bxRrSWHexQutNKLw6d7UnWTm2+gJ65Lsb1uNtPPmrEZ9ufJqkfzNz8AyiXDaJ62k kURvBARVsvIRPqynHAsXWnIazgykDzywYH9HuqbLLogyllb1GtYT00SiwybBpOTt IxAu/gIbwO2WaOaxzU+e4bHGXqMxwLjkA6UyNW+4az7mOh+EyjbQU/xYdo7Yhh4T ySlgZiWd/viHMqi4BHydh9/eU4FEs/9LGhlWyKbcb1paY/+SXSH8HHp6njUvmXYy lPa9ZJd4NJ/UqK3cNRjUmyAAV8Yw0xozy/CkYN5IvdwICbDTy8xvHTEbawvgWtc/ W8Whxo/AMSw8DYom3Y6H0D7XzQ+/a6EQSfpuDk2CQChn7MYEYrlEjMHtiMVts5nN CKwBXniom9fkbMkvIPWuA/htHRwTNj1VZ/ILCiXFQSWHpOmL7a7djpvnyGMOunI3 BqVEQM+KJuHSgKaFvXpgw4U43uq0mcH3ivzp51N3IvozzzQtKKHK3R5FDe1G0vlQ 8y8ojmN96RCVe74DzTe/oF6HhqccqrqOclGLKZX1IitGlsgJQokBD8ZQdkXIXAMP fQwPPo8QN/H0buIfvQtLu74ExPfARJVxl70WbcLt/2U4XrwYREi+83Nx1eUQk5BJ k838hddgFTe6PxZMw4zV =WdEt -----END PGP SIGNATURE----- --Edk6HoYKP7RsK9ib--