LDAP integration / ACL in Perl revisited

LDAP integration / ACL in Perl revisited

[Achim Gratz]

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 files
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" mount
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):

(1014) > getfacl bla
# file: bla
# owner: gratz
# group: Domain Users
user::---
group::---
group:+Authenticated Users:rwx
mask:rwx
other:---

(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


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?

   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, 0x600039498,
0x18032C9F0), file_attributes 32
12380  568906 [main] perl 5712 fhandler_base::fstat_helper: 0 = fstat
(\??\UNC\share\bla, 0x600039498) st_size=228, st_mode=0x81A4,
st_ino=8320105424607096594st_atim=53A96650.28F3A48 st_ctim=528DB9A1.13F33938
st_mtim=528DB9A1.4EE2D30 st_birthtim=528DB9A1.44615F0
   66  568972 [main] perl 5712 stat_worker: 0 = (\??\UNC\share\bla,0x600039498)
 3210  572182 [main] perl 5712 fhandler_pty_slave::write: pty0,
write(0x600082E00, 4)
   27  572209 [main] perl 5712 fhandler_pty_slave::write: (656): pty
output_mutex (0x184): waiting -1 ms
   24  572233 [main] perl 5712 fhandler_pty_slave::write: (656): pty
output_mutex: acquired
yes


Incredibly, this also works with the original script that led me onto this
hunt.  It runs a lot slower with all that stracing going on of course.

Ideas?

Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration / ACL in Perl revisited

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3155 bytes --]

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 files
> 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" mount
> 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):
> 
> (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
> 
> 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 

  $ 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 <<EOF
  use v5.10;
  say -R bla ? "yes" : "no";
  say -r bla ? "yes" : "no";
  say -O bla ? "yes" : "no";
  EOF
  $ perl x.pl
  no
  no
  no

I didn't try to debug this.

>    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, 0x600039498,
> 0x18032C9F0), file_attributes 32
> 12380  568906 [main] perl 5712 fhandler_base::fstat_helper: 0 = fstat
> (\??\UNC\share\bla, 0x600039498) st_size=228, st_mode=0x81A4,

(*) ...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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: LDAP integration / ACL in Perl revisited

[Achim Gratz]

Corinna Vinschen writes:
> 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 don't think I see this difference given the result from my script, but
I'll try to dig deeper tomorrow.

>> 12380  568906 [main] perl 5712 fhandler_base::fstat_helper: 0 = fstat
>> (\??\UNC\share\bla, 0x600039498) st_size=228, st_mode=0x81A4,
>
> (*) ...does not match that .........................^^^^^^^^^^^^^^

Could this be a result of running strace?  The previous "solution" to
this problem was to run the script with administrator rights (even
though that shouldn't change anything based on th ACL).  Could this end
up in a branch where the mode would be faked, like when mounting with
noacl (that would certainly result in a 644 mode)?

> Since test(1) is doing the right thing and returning the right results,
> I'm blaming perl for now.

Oh sure, there's something fishy going on with file tests in Perl.  I
just have no idea what it is yet…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration / ACL in Perl revisited

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> But when I run this via a perl script:
> 
>   $ cat > x.pl <<EOF
>   use v5.10;

This should be "use 5.14;" to do the same thing as "-E", I think.

> Since test(1) is doing the right thing and returning the right results,
> I'm blaming perl for now.

I've tested this again on a different file and a different machine and using
Cygwin32 via an admin CMD and a non-Admin one started from the same account.
 The straces this time are exactly identical save for the file handles, yet
the outcome of the test is "no" for non-Admin and "yes" for Admin
invocation.  Neither access nor euidaccess are called either way, so there
must be some heuristics in Cygwin Perl that try to infer access from the
stat information alone.  Why it doesn't pick up the fact that ACL are
involved I can't say.

The test executable on the other hand calls check_file_access, which then
traces into euidaccess.


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple