Bug #78566 for Date-Manip: taint problems with 6.32 Date::Manip::Parse

Wed Jul 25 11:08:37 2012 https://me.yahoo.com/danpritts#e36e1 - Ticket created

Subject:

taint problems with 6.32 Date::Manip::Parse

Hi, Having taint issues with Date::Manip::Parse 6.32. Other os and perl version info in attached file. On one of our systems, it worked; another failed the taint check and the module didn't successfully load. My colleague tracked it down to the contents of /etc/sysconfig/clock. One was America/Detroit and the other was America/New York. Of course, our staging server was Detroit and our production server was New York. I'm guessing you check this file for a time zone, do a sanity check, and then fail back to another method if the sanity check fails. Two-word values cause the failure; well, at least, America/El Salvador also failed. When this fails, we've noticed in strace output that it calls /bin/date; this is what causes the taint check to fail. Modifying the module source to explicitly set the $ENV{PATH}, or doing it in our own code in a BEGIN block, of course fixes the problem. Here's a test run showing the issue. /etc/sysconfig@top% cat ~danno/boof.pl #!/opt/perl-5.16.0/bin/perl -T use Date::Manip; $foo= ParseDate("1 January 2012"); print "foo is $foo\n"; and a test run: /etc/sysconfig@top% cat /etc/sysconfig/clock.ny # The time zone of the system is defined by the contents of /etc/localtime. # This file is only for evaluation by system-config-date, do not rely on its # contents elsewhere. ZONE="America/New York" /etc/sysconfig@top% cat /etc/sysconfig/clock.detroit # The time zone of the system is defined by the contents of /etc/localtime. # This file is only for evaluation by system-config-date, do not rely on its # contents elsewhere. ZONE="America/Detroit" /etc/sysconfig@top% sudo cp /etc/sysconfig/clock.ny /etc/sysconfig/clock /etc/sysconfig@top% ~danno/boof.pl Undefined subroutine &Date::Manip::ParseDate called at /usr/csg-nas/danno/boof.pl line 4. /etc/sysconfig@top% sudo cp /etc/sysconfig/clock.detroit /etc/sysconfig/clock /etc/sysconfig@top% ~danno/boof.pl foo is 2012010100:00:00 I'm not exactly sure what I want you to do about this, but one obvious answer is that you shouldn't be looking at /etc/sysconfig/clock on red hat systems, as per the comment in the file. Intermittent failures are a bitch. I'd rather have it fail taint, period, than have it borked in some time zones and not in others. thanks!

Subject:

versions.txt

[root@top sysconfig]# /opt/perl-5.16.0/bin/perl -e 'use Date::Manip; print DateManipVersion(1),"\n";' 6.32 [america/detroit] [root@top sysconfig]# /opt/perl-5.16.0/bin/perl -V Summary of my perl5 (revision 5 version 16 subversion 0) configuration: Platform: osname=linux, osvers=2.6.32-220.17.1.el6.x86_64, archname=x86_64-linux uname='linux staging.icpsr.umich.edu 2.6.32-220.17.1.el6.x86_64 #1 smp thu apr 26 13:37:13 edt 2012 x86_64 x86_64 x86_64 gnulinux ' config_args='-Dprefix=/opt/perl-5.16.0 -A ccflags=-fPIC -des' hint=previous, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fPIC -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC', optimize='-O2', cppflags='-fPIC -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include -fPIC -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC' ccversion='', gccversion='4.4.6 20120305 (Red Hat 4.4.6-4)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector' libpth=/lib64 /usr/lib64 /usr/lib64/mysql /opt/oracle/lib libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.12.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.12' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF Built under linux Compiled at Jul 19 2012 16:29:45 @INC: /opt/perl-5.16.0/lib/site_perl/5.16.0/x86_64-linux /opt/perl-5.16.0/lib/site_perl/5.16.0 /opt/perl-5.16.0/lib/5.16.0/x86_64-linux /opt/perl-5.16.0/lib/5.16.0 . [root@top sysconfig]# uname -a Linux top.icpsr.umich.edu 2.6.32-279.2.1.el6.x86_64 #1 SMP Thu Jul 5 21:08:58 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux [root@top sysconfig]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.3 (Santiago) [root@top sysconfig]# yum check-update Loaded plugins: downloadonly, product-id, protectbase, refresh-packagekit, rhnplugin, subscription-manager Updating certificate-based repositories. Unable to read consumer identity rhel-x86_64-server-6 | 1.8 kB 00:00 rhel-x86_64-server-optional-6 | 1.8 kB 00:00 rhel-x86_64-server-supplementary-6 | 1.8 kB 00:00 rhn-tools-rhel-x86_64-server-6 | 1.6 kB 00:00 0 packages excluded due to repository protections device-mapper-multipath.x86_64 0.4.9-56.el6_3.1 rhel-x86_64-server-6 device-mapper-multipath-libs.x86_64 0.4.9-56.el6_3.1 rhel-x86_64-server-6 kpartx.x86_64 0.4.9-56.el6_3.1 rhel-x86_64-server-6 [root@top sysconfig]#

Wed Jul 25 14:32:52 2012 sbeck [...] cpan.org - Correspondence added

You're correct in your analysis. Date::Manip tries several ways to determine the timezone and just keeps trying until it finds one that works. On unix (including RedHat) it does look in /etc/sysconfig/clock . On my redhat boxes, that file does not contain the comment you refer too, so I've never had any red flags about using that file as a possible source. In fact, your file contains two things that I haven't seen before: 1) it contains the comment you include, and 2) it does NOT include a valid timezone. The string: America/New York is NOT the name of a timezone. The string: America/New_York is. I've got a redhat 6.3 box and that's how it appears for me. Since I have constructed a regexp containing all of the known timezone names, I know what to look for. I could expand that regexp to change all '_' to ' ' of course, and I'll consider doing so, but I'm not immediately wanting to do that since that will make this horrendously huge regexp even bigger (and potentially slower) and that's not the actual name of the timezone anyway. I'm a bit curious how yours ended up with spaces in them. If it's something that redhat is doing standard in some situation, I'm willing to add the space names as a workaround. If it's something peculiar to your site, I'm less willing to do so. Do you know if your redhat installs are pretty much stock, or if you've getting timezone info from some nonstandard location? I know that ours are stock, and ours get the offical name (with underscore), but I'd like to get a bit more information before I move forward or reject this change. In any case, currently, since your /etc/sysconfig/clock file does not contain a recognized timezone, Date::Manip does move on to other methods including the /bin/date method. I'm going to do a bit more looking before I respond to the actual taint portion of your problem.

Wed Jul 25 14:32:53 2012 The RT System itself - Status changed from 'new' to 'open'

Wed Jul 25 14:49:52 2012 sbeck [...] cpan.org - Correspondence added

Could you add a line: $ENV{PATH} = '/bin:/usr/bin'; near the top of TZ.pm on the host where it's failing and try it again? Thanks

Wed Jul 25 15:56:27 2012 danno [...] umich.edu - Correspondence added

Subject:	Re: [rt.cpan.org #78566] taint problems with 6.32 Date::Manip::Parse
Date:	Wed, 25 Jul 2012 15:56:07 -0400
To:	bug-Date-Manip [...] rt.cpan.org
From:	Dan Pritts <danno [...] umich.edu>

Yeah, that fixes it of course. Not sure what the right solution is here - you could quite reasonably make an argument that we should be setting our path in taint mode and it's not your problem. It's the indeterminate behavior that is a killer. Also, I guess, using a file that the OS vendor specifically comments as "don't use this!" seems like bad form. But I know how it goes. :) thanks danno -- Dan Pritts ICPSR Computing and Network Services University of Michigan On Wednesday, July 25, 2012 at 2:49 PM, Sullivan Beck via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78566 > > > Could you add a line: > > $ENV{PATH} = '/bin:/usr/bin'; > > near the top of TZ.pm on the host where it's failing and try it again? > > Thanks

Wed Jul 25 16:08:41 2012 sbeck [...] cpan.org - Correspondence added

On Wed Jul 25 15:56:27 2012, danno@umich.edu wrote: Show quoted text

> Yeah, that fixes it of course.

That'll be in the next release for sure. Show quoted text

> > Also, I guess, using a file that the OS vendor specifically comments > as "don't use this!" seems like bad form. But I know how it goes. > :)

I agree... but the vendor didn't tell me "don't use this". Your vendor told you that... but as I mentioned, that comment isn't in mine (and incidentally, mine has a valid timezone while yours doesn't). The odd thing of course is that it appears that Redhat is the vendor in both cases. That's why I asked if there was anything odd about your install. I am confused about why your sysconfig/clock file is different than mine considering we're both using redhat.

Mon Jul 30 11:54:32 2012 sbeck [...] cpan.org - Correspondence added

Since the taint portion of the problem is fixed, and since I haven't heard back from you concerning the non-standard timezone entry (which doesn't match my entry on a similar system running the same version of redhat), I'm going to close this ticket without making any change to my existing timezone parsing. If you come up with additional information about why your system is using a non-standard timezone name, please reopen the ticket and I will consider changing the timezone regexps to allow that format. Thanks

Mon Jul 30 11:54:32 2012 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Jul 30 15:48:14 2012 danno [...] umich.edu - Correspondence added

Subject:	Re: [rt.cpan.org #78566] taint problems with 6.32 Date::Manip::Parse
Date:	Mon, 30 Jul 2012 15:48:03 -0400
To:	bug-Date-Manip [...] rt.cpan.org
From:	Dan Pritts <danno [...] umich.edu>

Hi, sorry for the slow response & thanks for fixing the immediate bug. I'm new at this site, so it took me a while to figure out how things were originally installed. I am as you surmised running RHEL6. I just did a couple RHEL6 installations as a test. a "workstation" install got a file like the ones I sent earlier. a "minimal" install got: ZONE="America/New_York" So for whatever reason, there are different code paths through anaconda, and one of them is busted. Which one is busted, I'm not sure :) -- Dan Pritts ICPSR Computing and Network Services University of Michigan On Wednesday, July 25, 2012 at 4:08 PM, Sullivan Beck via RT wrote: <URL: https://rt.cpan.org/Ticket/Display.html?id=78566 > On Wed Jul 25 15:56:27 2012, danno@umich.edu wrote: Yeah, that fixes it of course. That'll be in the next release for sure. Also, I guess, using a file that the OS vendor specifically comments as "don't use this!" seems like bad form. But I know how it goes. :) I agree... but the vendor didn't tell me "don't use this". Your vendor told you that... but as I mentioned, that comment isn't in mine (and incidentally, mine has a valid timezone while yours doesn't). The odd thing of course is that it appears that Redhat is the vendor in both cases. That's why I asked if there was anything odd about your install. I am confused about why your sysconfig/clock file is different than mine considering we're both using redhat.

Mon Jul 30 15:48:15 2012 The RT System itself - Status changed from 'resolved' to 'open'

Tue Jul 31 13:54:44 2012 sbeck [...] cpan.org - Correspondence added

Not sure why RHEL6 desktop is giving the timezones with spaces instead of underscores (that's definitely the one that's broken)... but since I'd like to support RHEL6, I added some support for this. As it turns out, it was an easy fix... I only added support for reading this type of timezone from a file (and I just preprocessed the values turning whitespace to underscore so I didn't need to adjust the timezone regexps). It'll be in the next release (6.33) due out in September (or you can contact me offline for a development copy before then).

Tue Jul 31 13:54:44 2012 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'