From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102062 invoked by alias); 10 Feb 2016 11:55: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 101505 invoked by uid 89); 10 Feb 2016 11:55:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-93.9 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=cygwin-ug-net, cygwinugnet, ntsechtml, UD:ntsec.html X-HELO: calimero.vinschen.de Received: from ipbcc0d020.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Feb 2016 11:55:08 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 94AB4A80591; Wed, 10 Feb 2016 12:55:06 +0100 (CET) Date: Wed, 10 Feb 2016 11:55:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Issues with ACL settings after updating to the latest cygwin.dll Message-ID: <20160210115506.GB15391@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20160208181956.GI12975@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eAbsdosE1cNLO4uF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-02/txt/msg00134.txt.bz2 --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4231 On Feb 9 20:53, xnor wrote: >=20 > >Not sure what Transmission is, but files downloaded with POSIX > >tools are usually not executable. For instance, download Cygwin's > >setup-x86.exe with wget. Then try to execute it. It won't since > >the permissions are set according to your umask and without execute > >permissions, e.g., 0644. This is normal. > The behavior has changed with the ACL change in Cygwin and I would not > consider that "normal". The warning from Windows is not normal. Which warning do you mean here? > I realize that the previous implementation was already problematic and > messed with permissions but I did not notice it since it never denied > executing executables. No, but either way, the created ACL is not necessarily what Microsoft describes as "canonical". POSIX permissions just don't map well with canonical-only ACLs. The problem right now is that I can't reproduce what you encounter. That's why I'm asking for the details in terms of the ACL, that is, output from icacls and getfacl to compare the output and ideally being able to reproduce and, even more ideal, fix it. Come on, be fair. The new ACL handling started out early 2015, got a break when I realized that it doesn't work as is, and then got a new test phase starting back in September. Except for minor bugs it seemed to work rather well. Nobody reported this effect in all the 4 months of test period. You don't actually think I wouldn't have fixed it prior to the release if I had known about it, do you? > >The permissions must *not* be reordered. If Cygwin creates permissions > >incorrectly it's one thing, but the order to emulate POSIX permissions > >is non-canonical. Reordering them will break them. > > > >Please provide the exact output from icacls. > They *have* to be reordered to be modifiable in Windows/Explorer. In other > words, if I want to change permission the new ACL behavior ensures that it > breaks the Cygwin permissions? They are not supposed to be modifiable in Explorer. If you want to change permissions on a Cygwin ACL, use chmod or setfacl. > Here is the output from icacls /saveacl for some file: > D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-201= 9639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5= -21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)= (A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD) Doh, I'm sorry, but I can't read this format very well. Can you please again send the standard icacls output as well as the output from getfacl of the parent dir and the created file? I'd like to have this problem fixed, but I need your help. As I said, it works fine for me and without being able to reproduce I'm somewhat at a loss. > Here is what's "normal" for Windows if I create a file under a new folder= on > C: in Explorer: If you don't want POSIX perms, but standard Windows perms, use the "noacl" mount option. See https://cygwin.com/cygwin-ug-net/using.html#mount-table > Here is what I would expect: > MyUser is in the group Administrators. Given the inherited permissions ab= ove > a Windows-created file should be shown as "-rwxrwxr--+ MyUser > Administrators"? Sorry, can't do that, *unless* you make "Administrators" the primary group in your user token(*). Even though your account is *member* of the Administrators group, the group is *never* your primary group per Windows. All local accounts, independently of their group memberships, have the group "None" as their primary group. That's how Windows works, and that hasn't changed since at least NT4. Unless, of course, if you use a so-called "Windows account", one of those accounts which you login with using your email address (was that introduced with Windows 8? I'm not sure). In that case, the primary group in your user token is set to your user account itself. So your primary group SID is your own user SID. Duh! Corinna (*) There *is* a way to do that, but only inside Cygwin, see https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-passwdinfo --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --eAbsdosE1cNLO4uF Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWuyUaAAoJEPU2Bp2uRE+gNR0P/ii4VcTJB2edvuHvGiSdd7gC 532k6O9hjQmT0BuJzAUe3Yp13uwmEIpZ5m5vEzCn3rxgtYtRpSlOBC6RzWp/yH8k iAqPYvsiyu2CVomWAqVDvc7Xh3+1e4eTnz6wLsIdVsu+wbTAZrimAWDztCmiO6Jh bYyQorFRFli0JnRNc+CSKB/6Ps3rE8SoMmlglCe60+eirIGSz8gWNDxYqZf3yG3U fInEviSiJAh8v1CAH3hswC+SMl8U3GvZOfZkMFIIGOu1umqhum8FdcZ7EjKc7QnS 2jsrKEzaxe4wpNMA7E0jmKFKX/PbjCbIm7JczG6JmkSB775JkYxW8VRwLJrIsq8C zxiZ3dOOYv7bL+LGF6lQ6kFq+q6hW14XG2npWdLrpLa3guJ7exYTE1fIK3GhjTM3 /d/XihumbWfmC4Ms1DwIJM0Uu9q8dvGPQzZtPj81NSoIkLD51bhNS9Ymie6+HcyL vOzvmm6x5H9VbmlDAeWseHtgFsfcLBvNRjlU3V1J9PxrVf971vdRv6GtRFY+ck7s f9tIQVQuN7iKPIHPhQ6gs14psxEhUgBiRvKqgBjNAc5cSuAuKGwUEefcJ7RoRBQ+ DFNMZgU/NgYHLrDiE0CIkTdN6HBB8v5a/TTYxH0ApVjs4kSugP4XoS5a5+PH+llY 6ShCaSKaUO7G/OU4oQvv =bcOq -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF--