Discussion:
[perl #125740] [PATCH] t/op/stat.t: skipping -r test is unneeded
via RT
2015-08-03 09:26:59 UTC
Permalink
# New Ticket Created by
# Please include the string: [perl #125740]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=125740 >


This is a bug report for perl from ***@mail.mipt.ru,
generated with the help of perlbug 1.40 running under perl 5.23.2.


-----------------------------------------------------------------
[Please describe your issue here]

Subj. The -r test works just fine in Cygwin 2.1.0.

I couldn't find a note in Cygwin git repo on
whether this had been changed as some point
and don't have an ancient Cygwin version to test
this directly.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=low
Type=Patch
PatchStatus=HasPatch
---
Site configuration information for perl 5.23.2:

Configured by User at Sat Aug 1 13:47:55 AST 2015.

Summary of my perl5 (revision 5 version 23 subversion 2) configuration:
Local Commit: a90ad6d3cfecd7f26e2a8932159963ea31307bca
Ancestor: 85d323d4d59cc15f5c76bca4c1df90317f88d0e8
Platform:
osname=cygwin, osvers=2.1.0(0.28753), archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 iru-notebook 2.1.0(0.28753) 2015-07-14 21:26 i686 cygwin '
config_args='-Dprefix=/opt/perl5 -Dusedevel -de'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
use64bitint=define, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong'
ccversion='', gccversion='4.9.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678, doublekind=3
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12, longdblkind=3
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lpthread -ldl -lcrypt
perllibs=-lpthread -ldl -lcrypt
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=cygperl5_23_2.dll
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -L/usr/local/lib -fstack-protector-strong'

Locally applied patches:
a90ad6d3cfecd7f26e2a8932159963ea31307bca

---
@INC for perl 5.23.2:
lib
/opt/perl5/lib/site_perl/5.23.2/cygwin-thread-multi-64int
/opt/perl5/lib/site_perl/5.23.2
/opt/perl5/lib/5.23.2/cygwin-thread-multi-64int
/opt/perl5/lib/5.23.2
.

---
Environment for perl 5.23.2:
CYGWIN=nodosfilewarning
HOME=/home/User
LANG=ru_RU.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/local/bin:/usr/bin:/c/bin/rk:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/system32/WBEM:/usr/local/bin:/usr/bin:/:/c/bin:/c/Program Files/Java/jdk1.7.0_12/bin:/c/Program Files/QT Lite/QTSystem:/c/Program Files/TortoiseHg:/c/ant/bin:/c/apache-maven-3.0.4/bin:/c/Program Files/TortoiseSVN/bin:/c/Py/Scripts:/c/Py:/c/Program Files/TortoiseGit/bin:/c/Program Files/Git/cmd:/c/program files/Java/jdk1.6.0_22/bin:/c/program files/vim/vim71:/c/py:/c/Py/Scripts:/c/Program Files/PuTTY:/c/Program Files/Nmap
PERL_BADLANG (unset)
SHELL=/bin/bash
Tony Cook via RT
2015-08-04 00:52:06 UTC
Permalink
Post by via RT
Subj. The -r test works just fine in Cygwin 2.1.0.
I couldn't find a note in Cygwin git repo on
whether this had been changed as some point
and don't have an ancient Cygwin version to test
this directly.
When Merijn added you to AUTHORS he added you with email address <***@mail.mipt.ru> which is the email address used in your "[PATCH] configure: -error when default output is not a.aot - errors when build path has spaces" email.

This new patch uses <***@mail.ru>.

Do you have a preference?

Tony

---
via perlbug: queue: perl5 status: new
https://rt.perl.org/Ticket/Display.html?id=125740
Ivan Pozdeev
2015-08-04 06:50:49 UTC
Permalink
Post by Tony Cook via RT
When Merijn added you to AUTHORS he added you with email address
configure: -error when default output is not a.aot - errors when build path has spaces" email.
Do you have a preference?
Tony
The former. I dunno why the latter slipped through - must be an
oversight.
--
Regards,
Ivan Pozdeev
Ivan Pozdeev
2015-08-04 06:53:09 UTC
Permalink
Regarding the ticket's matter:
I found it.

Cygwin commit https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=2c1ffdbf5e6f2767ab63e67834530539d36c6c0b
from 16 Oct 2006, winsup/cygwin/security.cc,
actually _enabled_ security override.

In actuality, they report read access regardless of ACL
if the user has SeBackupPrivilege enabled.

It is disabled by default, even for admins.
(The secpol.msc "Back up files and directories" setting
only allows a program to enable it on request.)

BUT: Cygwin processes always enable this privilege
(thus, so does Perl built for Cygwin).

Despite this, Perl still reports -r correctly, even with this privilege set.
Shall I investigate the reason further ot this is proof enough?
--
Best regards,
Ivan mailto:***@mail.mipt.ru
Tony Cook via RT
2015-08-11 00:47:15 UTC
Permalink
Post by Ivan Pozdeev
I found it.
Cygwin commit https://cygwin.com/git/gitweb.cgi?p=newlib-
cygwin.git;a=commit;h=2c1ffdbf5e6f2767ab63e67834530539d36c6c0b
from 16 Oct 2006, winsup/cygwin/security.cc,
actually _enabled_ security override.
In actuality, they report read access regardless of ACL
if the user has SeBackupPrivilege enabled.
It is disabled by default, even for admins.
(The secpol.msc "Back up files and directories" setting
only allows a program to enable it on request.)
BUT: Cygwin processes always enable this privilege
(thus, so does Perl built for Cygwin).
Despite this, Perl still reports -r correctly, even with this
privilege set.
Shall I investigate the reason further ot this is proof enough?
I wasn't able to get cygwin to set $> to 0 (which would skip the test anyway) and the test passes when not skipped, so it's all good.

Thanks, applied as 9728ed0a4dcaca9d7fddf6ce9c5736ed3aacd487 with the adjusted author as discussed previously.

Tony

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=125740
Achim Gratz
2015-08-11 05:55:03 UTC
Permalink
Post by Tony Cook via RT
Post by Ivan Pozdeev
BUT: Cygwin processes always enable this privilege
(thus, so does Perl built for Cygwin).
You can drop privileges as well as membership in the Administrator group
with cygdrop. Specifically, if you want to do both:

cygdrop -lm <command>
Post by Tony Cook via RT
Post by Ivan Pozdeev
Despite this, Perl still reports -r correctly, even with this
privilege set.
Shall I investigate the reason further ot this is proof enough?
I wasn't able to get cygwin to set $> to 0 (which would skip the test anyway) and the test passes when not skipped, so it's all good.
You can't have UID zero on Windows and there is no root user either.
You can fake that in Cygwin via /etc/passwd if you really want to, but
it's not making the tests for "root" work correctly anyway. If you need
to test for something that's approximating root, then you need to check
for group 544. It's still not the same thing as being root, mind you.
There's even a library that fakes the euid to zero for programs from
UNIX. I haven't applied it to Cygwin Perl since I don't think that Perl
should lie about the uig/gid, though.
Post by Tony Cook via RT
Thanks, applied as 9728ed0a4dcaca9d7fddf6ce9c5736ed3aacd487 with the adjusted author as discussed previously.
The tests that fail if you are admin are mainly the -w tests, IIRC.
Last but not least, the results very much depend on whather the file
system you run the tests on uses ACL and how they are set. Cygwin has
recently learned to deal with Windows ACL much more thoroughly, however
some setings just can't map to POSIX and the resulting mode bits can be
quite confusing.

In particular, if your access is granted only via inherited ACL (which
is common on network shares), the file ownership is recorded with your
UID and you are not allowed to change the ACL, then Cygwin has no way of
setting the POSIX mode bits correctly. In those cases the user bits are
all cleared and the group bits reflect the access via ACL, which in
POSIX means the user has explicitly been shut out from accessing the
file (the group bits and the ACL will never be checked), while Windows
processes the ACL in a slightly different way and allows the access.


So, as said before: Since some of the tests require certain privileges
to be present, other tests require the same privileges to be absent and
checking for the user being "root" is at best an incomplete proxy for
the status of those privileges (even on UN*X if you have SELinux or some
other MAC extension enabled), the correct way of dealing with those
tests would be to drop privileges when they are not needed and skip
tests when you have insufficient privileges. That, however requires a
bit of infrastructure that isn't there yet.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Ivan Pozdeev
2015-08-11 06:46:21 UTC
Permalink
Post by Tony Cook via RT
Thanks, applied as 9728ed0a4dcaca9d7fddf6ce9c5736ed3aacd487 with
the adjusted author as discussed previously.
Aaahhh... don't be so rash!

In the meantime, I finished the investigation.

And it showed: Perl _is_ designed to always report access
for admin in Cygwin, but it doesn't check the group membership
correctly.

So, this test succeeds when it shouldn't!

I thought to devise a patch to add a specific test case for admins
(that would fail) before reporting all this to as not to come
with just complaints and no solution (which would only get me
jettisoned from the community since it's the most despicable thing to
do ever).

Apparently, my decision was misguided!

Anyway, there's no need to revert the commit, just don't lock the
ticket until the real solution is applied.
--
Regards,
Ivan Pozdeev
Loading...