From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3271 invoked by alias); 12 Apr 2015 08:22:16 -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 3257 invoked by uid 89); 12 Apr 2015 08:22:15 -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; Sun, 12 Apr 2015 08:22:14 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 54161A809F2; Sun, 12 Apr 2015 10:22:12 +0200 (CEST) Date: Sun, 12 Apr 2015 08:22:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: [TESTERS needed] New POSIX permission handling Message-ID: <20150412082212.GL7343@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20150410100703.GA4401@calimero.vinschen.de> <20150411094020.GB19111@calimero.vinschen.de> <20150411100752.GE19111@calimero.vinschen.de> <55294B35.8050708@raelity.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5uO961YFyoDlzFnP" Content-Disposition: inline In-Reply-To: <55294B35.8050708@raelity.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00230.txt.bz2 --5uO961YFyoDlzFnP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1696 On Apr 11 09:26, Ernie Rael wrote: > I'm primarily a lurker, reading this list hoping things soak in a bit. So= I > may be off base on this. >=20 > In the table below, describing "NULL DENY access mask", looks like there'= s a > typo concerning read/execute. (of course it might just be a windows mappi= ng > peculiarity that I really didn't want to know about ;-) Hey, cool, somebody noticed :) And since you asked, you'll get to know, whether you want or not ;) > >The following bits in the NULL DENY access mask are used: > > > > Windows access <-> POSIX access > > -------------- ------------ > > FILE_READ_DATA S_ISVTX > > FILE_WRITE_DATA S_ISGID > > FILE_APPEND_DATA S_ISUID > > > > FILE_READ_EA MASK S_IXOTH (POSIX execute perms) > > FILE_WRITE_EA MASK S_IWOTH (POSIX write perms) > > FILE_EXECUTE MASK S_IROTH (POSIX read perms) >=20 > Are read and execute swapped intentionally in the above? Yes, indeed. since the NULL access mask is not needed for actual permission checking by Windows, we can use the bit as they fit our needs. The reason for using them in this order are their bit values. FILE_READ_EA =3D=3D 0x08 S_IXOTH =3D=3D 0x01 FILE_WRITE_EA =3D=3D 0x10 S_IWOTH =3D=3D 0x02 FILE_EXECUTE =3D=3D 0x20 S_IROTH =3D=3D 0x04 To convert from Windows to POSIX and vice versa, a simple shift operation is sufficient. Reordering just to fit the symbolic name would complicate the conversion unnecessarily. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --5uO961YFyoDlzFnP Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVKis0AAoJEPU2Bp2uRE+g8LsP/RHOsc5ETF+pVuRdOI9X7f+1 NKYdzpmaDA+mG+0/M8Nlgap6QtH6GRL83Jx9KlLiHtNHO5zjPEaQXlH10Il4IDmJ HlmgMxZdMaayfW6R2Db/KDvwTfgNupsQkK1zlX8uNIqZRhFJ1Ky6m82QcxsK6rXu qKk97VCwxnT/wu9u2BZ7dxg61cWWo+qjKtCQfSoZHbH8Gi7v3gSel5h/Ye8Q9oZ2 ssxbw47Zdve9jalE9vKJCwAg7InOkU1N2ssAl33IsT4iVZQuC02ZJ1Siciq/DyA5 UMq17SEYl+YExBU4n7U0Lz0MHDSPOPZx0+D389BDYVWq/jkEg98eRINaCfdfH7E8 18RRbf2qscZ0qDgQQgXS5gRBKgtBBG/r81Ql3oPFtJkISg6LqR/Ok3GnBAdkn6nE 7tz2Tlhud4Dorh0kzduhDHShwXgYbe9ulFi/iPbbO0iAvFY5Q3YebUyAacpIwpr8 v7f9Bgf9sqy0HhctYHszVKsNiH0uXhWyvj+iWfpWWFhdbtPYvmUAf/DQvbbl7Qx0 VPK8OA0MhH8fkJ+gB+xX9SSdkHgYom65d+HMLjyz5yeIEl1sZZp3EtbwAJOFMseW 3HmsxMQQkTV7eCqX3ycXKrPSWJwE8rBv17rU9uY4h/H/pKNFivanNoYaTmifDHzQ fldQxH7AtPx8XGe7f4f4 =ydrU -----END PGP SIGNATURE----- --5uO961YFyoDlzFnP--