From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4978 invoked by alias); 24 Jun 2014 17:13: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 4966 invoked by uid 89); 24 Jun 2014 17:13:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_50 autolearn=ham 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; Tue, 24 Jun 2014 17:13:09 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 522F48E13F9; Tue, 24 Jun 2014 19:13:06 +0200 (CEST) Date: Tue, 24 Jun 2014 17:13:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: LDAP integration / ACL in Perl revisited Message-ID: <20140624171306.GK1803@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cN519qCC4CN1mUcX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-06/txt/msg00381.txt.bz2 --cN519qCC4CN1mUcX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3076 On Jun 24 12:18, Achim Gratz wrote: > I've just set up a new machine with Cygwin (64bit w/ the 2014-06-23 13:20= :35 > snapshot), nsswitch.conf specifies "db" for both passwd and group (the fi= les > have been moved away just to be sure they aren't picked up). I have one > share with somewhat strange ACL that I always had to use via a "noacl" mo= unt > option. I thought I should try again and this is what happened (bla is a > file that has non-zero size and is owned by me): >=20 > (1014) > getfacl bla > # file: bla > # owner: gratz > # group: Domain Users > user::--- > group::--- > group:+Authenticated Users:rwx > mask:rwx > other:--- ^^^^^^^ This... (*) > (1015) > [ -r bla ] && echo Hello... > Hello... > (1018) > perl -E 'say -R "bla" ? "yes" : "no"' > no > (1016) > perl -E 'say -r "bla" ? "yes" : "no"' > no > (1017) > perl -E 'say -O "bla" ? "yes" : "no"' > yes >=20 > So for whatever reason Perl still doesn't deal correctly with those ACL, > while the shell test operator does. Now the kicker: if I run Perl under > strace, the test succeeds... huh? Without pulling strace into the picture, I get different results for -O depending on whether running this on the command line as above, or if I run this via a perl script. I prepared a file with permissions equivalent to the above getfacl output: $ getfacl bla # file: bla # owner: corinna # group: vinschen user::--- group::--- group:+Authenticated Users:rwx mask:rwx other:--- This results in=20 $ perl -E 'say -R "bla" ? "yes" : "no"' no $ perl -E 'say -r "bla" ? "yes" : "no"' no $ perl -E 'say -O "bla" ? "yes" : "no"' yes But when I run this via a perl script: $ cat > x.pl < 26 556465 [main] perl 5712 path_conv::check: this->path(\\share\bla), > has_acls(1) > 34 556499 [main] perl 5712 build_fh_pc: fh 0x18032C9F0, dev 000000C3 > 27 556526 [main] perl 5712 stat_worker: (\??\UNC\share\bla, 0x6000394= 98, > 0x18032C9F0), file_attributes 32 > 12380 568906 [main] perl 5712 fhandler_base::fstat_helper: 0 =3D fstat > (\??\UNC\share\bla, 0x600039498) st_size=3D228, st_mode=3D0x81A4, (*) ...does not match that .........................^^^^^^^^^^^^^^ The getfacl permissions look like the last 9 bits of st_mode should have been 000 octal, but the above st_mode is equivalent to 0644 permissions. That's weird. It does not happen for me, st_mode is 0100000, as expected. If perl really only calls stat to check the POSIX permission bits (as the strace output suggests, I checked mine), that would account for the "no" in the -r/-R case. What it should do is calling euidaccess/access, or faccessat as test(1) does. Since test(1) is doing the right thing and returning the right results, I'm blaming perl for now. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --cN519qCC4CN1mUcX Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTqbGiAAoJEPU2Bp2uRE+g9nkP/1Q7V0aMdc8344KyiBWy5JU2 uVnhlmUTZkKYj/5DJfjTkd9uw3A7JKit9PRusp8OCEuk2NI47ffPW4Eej15xsfLc LO2sO8e8hPatbplVIgrtS7WwdxAbLSB5H7dcPQk/L6mygyiKm7Lu9a3QCPqlHmK3 OpPp4ayBMwVeQY+3Oqo37LJnxiDbFV0rrlW7HaaYBSwtIhAqWEM+77oAyE8lS2rC X5MTzfg/sxuXhtwh+uHFCyoasyQbNWHGgTz9gKpvr/2JAxUhmRSWboc3BV3bRFng Orpo//bRkFldtnepeSvake+x4ViLRMpSDW1FvNbxV4fa2TJYZXfuSm66MiC1yINo se//qZ/gQt+NOdjIkhMweiJeV9nb5A073HCGIeoQqBVvkYyqylR373PAEXEjfVYP zMcByVt7nfHvMbDcc6X/jOYZAk00Vgjv02YGFI7rUdPjRq2uFWw1Vz9RQ2aOHiCS bG9Js6nafkrq6+Efxpq/eKMEpXABGTUqJau84D3IOoHbghF4+Wmbj1NZ7ABdt8vJ X9Adu3XuLrT3Rf3gWSlXRejhjXTQsM7UOW+s/fgDmsS376yMn2GR7T5NBtei2+6O zPP10ogSpAkGAN6dHUO64nTJHhMHtab5XlKKDql4TApz5IBPoyrIa/JJHsR0BhSQ w3F39OwizfTLguuRr5dn =2/Ce -----END PGP SIGNATURE----- --cN519qCC4CN1mUcX--