Re: efficient module version checking without loading the module?
On Wed, Mar 24, 2004 at 12:20:58PM -0800, Stas Bekman wrote: I completely agree with you, Hugo. But I'm also sure that you know that when something doesn't work under -T a frustrated user simply turns it off. So: Well yes it does, in an untainted environment is really, not it doesn't work. I'd rather relax taint checking in certain places, rather than have the user turn it off completely. Certainly documenting the issue should be helpful. Whether relxed tainting is superior to no tainting is surely dependent on your view of tainting, to whit: 1) If tainting is a security measure to prevent malicious attackers (e.g., as used in suid scripts), then a relaxed tainting provides a false sense of security, and at least no tainting lets you know that the script is not to be trusted. 2) If tainting is a bit like warnings, in that it's a helpful warning measure to assist in catching a number of common issues but not a guarantee of anything, then as you say, a relaxed taint that's used is better than none at all. Mx.
Re: efficient module version checking without loading the module?
Martyn J. Pearce wrote:
On Wed, Mar 24, 2004 at 12:20:58PM -0800, Stas Bekman wrote:
I completely agree with you, Hugo. But I'm also sure that you know that
when something doesn't work under -T a frustrated user simply turns it off.
So:
Well yes it does, in an untainted environment
is really, not it doesn't work. I'd rather relax taint checking in certain
places, rather than have the user turn it off completely. Certainly
documenting the issue should be helpful.
Whether relxed tainting is superior to no tainting is surely dependent on your
view of tainting, to whit:
1) If tainting is a security measure to prevent malicious attackers (e.g., as
used in suid scripts), then a relaxed tainting provides a false sense of
security, and at least no tainting lets you know that the script is not to be
trusted.
2) If tainting is a bit like warnings, in that it's a helpful warning measure
to assist in catching a number of common issues but not a guarantee of
anything, then as you say, a relaxed taint that's used is better than none at
all.
Agreed for the general case. But it doesn't apply to this case. Because:
#!/usr/bin/perl -T
require Foo;
print $Foo::Version;
and
#!/usr/bin/perl -T
my $version = parse_version_untaint_source('Foo');
print $version;
are *exactly* the same from the security point of view, because require()
ignores the tainting flag.
So if you *do* trust require() of a random file to acquire its version, you
ought to trust parse_version_untaint_source() just the same.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: efficient module version checking without loading the module?
On Mar 24, 2004, at 2:20 PM, Stas Bekman wrote: That's said, it'd be great to see the perl test suite run all its tests under -T. I thought we have discussed this about a year ago or so. I'm not sure that's a good idea. Aren't there tests in the suite that invoke system-level operations on data that comes from outside the test scripts? -Ken
Re: efficient module version checking without loading the module?
On Mar 25, 2004, at 2:31 PM, Stas Bekman wrote: So if you *do* trust require() of a random file to acquire its version, you ought to trust parse_version_untaint_source() just the same. It's not obvious to me that eval-ing an arbitrary (or semi-arbitrary) line of a file is always as safe as eval-ing the entire file. Consider the following highly contrived example: package FoolMeTwice; my $string = 'EOF'; $VERSION = 5; system(rm -rf /); EOF $VERSION = 6; __END__ That will do almost nothing with use FoolMeTwice;, but doing parse_version_untaint_source() will wreck your system. Maybe there are no non-contrived examples, though. -Ken
Re: efficient module version checking without loading the module?
Ken Williams wrote: On Mar 25, 2004, at 2:31 PM, Stas Bekman wrote: So if you *do* trust require() of a random file to acquire its version, you ought to trust parse_version_untaint_source() just the same. It's not obvious to me that eval-ing an arbitrary (or semi-arbitrary) line of a file is always as safe as eval-ing the entire file. Consider the following highly contrived example: package FoolMeTwice; my $string = 'EOF'; $VERSION = 5; system(rm -rf /); EOF $VERSION = 6; __END__ That will do almost nothing with use FoolMeTwice;, but doing parse_version_untaint_source() will wreck your system. Maybe there are no non-contrived examples, though. OK, I stand corrected. Thanks Ken. In which case using laundering and eval'ing in the Safe compartment is probably the best idea. Though if I remember correctly Safe has lots of problems (doesn't quite work in certain environments), so I'm not sure how practical it is. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: efficient module version checking without loading the module?
David Nicol wrote: Stas Bekman wrote: In which case using laundering and eval'ing in the Safe compartment is probably the best idea. Though if I remember correctly Safe has lots of problems (doesn't quite work in certain environments), so I'm not sure how practical it is. What's the advantage of that over opening the file for reading and looking for /\$VERSION\s*=\s*([^\s\;]+)/ in it? (adjust the regex some to handle quoting if needed) If it was that simple do you think MM::parse_version wouldn't have done just that. Unfortunately it's not. Adjusting the version search regex to handle problems such as the version is deswcribed on multiple lines, or the version is described within quotes -- workarounds are possible, but it seems like documenting that that is what your version checker does and doing it instead of trying to compensate for all edge cases would be a reasonable approach. That's is what documented: http://pause.perl.org/pause/query?ACTION=pause_04about Other conventions you should know about [...] Please make sure all your *.pm files contain a $VERSION variable that conforms to the CPAN rules, i.e. the complete computation of $VERSION must take place on the one first line within the module that assigns to it. You can test if this is the case by running perl -MExtUtils::MakeMaker -le 'print MM-parse_version(shift)' 'file' on the filenames in question. The CPAN indexer will run this code within a Safe compartement, so maybe even if the above command succeeds, PAUSE may fail if you're doing file IO or other potentially dangerous things within that line. As usual, i might not know what I'm talking about. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
