Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
Geoffrey Young wrote:
By splicing you mean 'Include ken_extra.conf' from t/conf/httpd.conf?
Yes, but have_module() doesn't look it up in any of the conf files, it
looks it up from the config object $cfg->{modules} which get populate
with available modules when the config is generated, and it only scans
the inherited file, it doesn't scan any of the files in t/conf.
no, what I meant was that ken_extra.conf (httpd.extra.conf.in ->
httpd.extra.conf) would get appended to the currently generated httpd.conf,
then _that_ result is what is scanned. but maybe it's not as simple to
change the internal logic to accomodate that.
But we don't scan anything in t/conf/, besides replacing @vars@ and assigning
ports. You will have to change the logic to do that. Therefore inhereted
config is a perfect fit, since we do scan it for LoadModule directives.
anyway I was just making a suggestion - it seems limiting to me not to
have
substitution in extra configuration files,
But that's exactly what Ken doesn't want. He wants to give his own file
which he has cooked already. This new option and your suggestion don't
contradict each other. and each has a merit for existence.
I still don't see how the idea I'm proposing isn't sufficient, save that it
would need to live within t/conf. that we could make it support variable
substitution doesn't mean that it can't be 100% hard-coded.
It just won't work the way things are now. Again, what Ken needs is scanning
of LoadModule directives.
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
> By splicing you mean 'Include ken_extra.conf' from t/conf/httpd.conf?
> Yes, but have_module() doesn't look it up in any of the conf files, it
> looks it up from the config object $cfg->{modules} which get populate
> with available modules when the config is generated, and it only scans
> the inherited file, it doesn't scan any of the files in t/conf.
no, what I meant was that ken_extra.conf (httpd.extra.conf.in ->
httpd.extra.conf) would get appended to the currently generated httpd.conf,
then _that_ result is what is scanned. but maybe it's not as simple to
change the internal logic to accomodate that.
>> anyway I was just making a suggestion - it seems limiting to me not to
>> have
>> substitution in extra configuration files,
>
>
> But that's exactly what Ken doesn't want. He wants to give his own file
> which he has cooked already. This new option and your suggestion don't
> contradict each other. and each has a merit for existence.
I still don't see how the idea I'm proposing isn't sufficient, save that it
would need to live within t/conf. that we could make it support variable
substitution doesn't mean that it can't be 100% hard-coded.
>
>> or to be able to specify one kind
>> of config file from the command line but not others. but it's not like I
>> have the tuits to do anything about it now anyway, so I guess it stays
>> as is :)
>
>
> :)
:)
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
Geoffrey Young wrote:
I wasn't clear enough, but the proposed httpd.extra.conf.in
would be
appended to the generated httpd.conf rather than pulled in via Include.
would that not suit the needs that the current patch resolves?
Please see below
would there really be a need to pull in more than one config into the
main
httpd.conf that couldn't be met via Include?
No, have_module() won't see those modules. It must be parsed via
inheriting scheme or come up with a new way. the new option seems to be
the simplest solution.
I don't see your point here. once you splice together the current
httpd.conf with the new file (however it's generated) have_module would have
access to the information it needs.
By splicing you mean 'Include ken_extra.conf' from t/conf/httpd.conf? Yes, but
have_module() doesn't look it up in any of the conf files, it looks it up from
the config object $cfg->{modules} which get populate with available modules
when the config is generated, and it only scans the inherited file, it doesn't
scan any of the files in t/conf.
Ken doesn't want it to be inside t/conf/, since he will have it
elsewhere. He doesn't want to touch the A-T project's file. That's what
I understood.
ok, that's a valid reason.
anyway I was just making a suggestion - it seems limiting to me not to have
substitution in extra configuration files,
But that's exactly what Ken doesn't want. He wants to give his own file which
he has cooked already. This new option and your suggestion don't contradict
each other. and each has a merit for existence.
or to be able to specify one kind
of config file from the command line but not others. but it's not like I
have the tuits to do anything about it now anyway, so I guess it stays as 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
>> right, I think I got that. but that requires knowing the hard-coded >> path. > > > That's what Ken wanted ok, but just because you get substitution doesn't mean you have to use it :) > >> perhaps I wasn't clear enough, but the proposed httpd.extra.conf.in >> would be >> appended to the generated httpd.conf rather than pulled in via Include. >> would that not suit the needs that the current patch resolves? > > > Please see below >> would there really be a need to pull in more than one config into the >> main >> httpd.conf that couldn't be met via Include? > > > No, have_module() won't see those modules. It must be parsed via > inheriting scheme or come up with a new way. the new option seems to be > the simplest solution. I don't see your point here. once you splice together the current httpd.conf with the new file (however it's generated) have_module would have access to the information it needs. > > Ken doesn't want it to be inside t/conf/, since he will have it > elsewhere. He doesn't want to touch the A-T project's file. That's what > I understood. ok, that's a valid reason. anyway I was just making a suggestion - it seems limiting to me not to have substitution in extra configuration files, or to be able to specify one kind of config file from the command line but not others. but it's not like I have the tuits to do anything about it now anyway, so I guess it stays as is :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
Geoffrey Young wrote: That probably won't suite Ken's particular need. What Ken was after is to be able to throw random .so modules into some directory and tell Apache::Test to detect them, load them and have have_module() see them. and Ken really wants to have lots of these directories and point every time to a different one. So all he does now is generating a simple extra.conf which only lists LoadModule directives with the correct path to those modules, A-T picks them up and doesn't require c-modules any longer (Ken wants to pre-build c-modules for many architectures and many apache versions). right, I think I got that. but that requires knowing the hard-coded path. That's what Ken wanted perhaps I wasn't clear enough, but the proposed httpd.extra.conf.in would be appended to the generated httpd.conf rather than pulled in via Include. would that not suit the needs that the current patch resolves? Please see below I like this Ken's new option because it'll suite cases where a user can't modify the global httpd.conf, but will be able to add its own global httpd.conf extra's via this option. We have also discussed to make it accept more than one file, but at the moment it's not possible and will require quite a few changes (currently config is a hash and it's set in more than one place). doable, but we probably shouldn't touch it until someone will really need it. would there really be a need to pull in more than one config into the main httpd.conf that couldn't be met via Include? No, have_module() won't see those modules. It must be parsed via inheriting scheme or come up with a new way. the new option seems to be the simplest solution. Ken doesn't want it to be inside t/conf/, since he will have it elsewhere. He doesn't want to touch the A-T project's file. That's what I understood. While we discussed possible solutions, I suggested an idea to figure out whether we have a compiler at all, and if not skip even trying to build c-modules. So if you build things on machine A with a compiler and then tar things up and move it to machine B w/o a compiler (same architecture), the modules will be already precompiled and ready to use and t/TEST -clean won't nuke them. Ken said that this idea didn't suite him, but I think it could be useful to others. The kludge is how to figure out whether things will be able to compile or not (whether there is a compiler at all). yes, it's a separate issue but a good idea as well. But again, this is something to consider in the future. __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
> That probably won't suite Ken's particular need. What Ken was after is > to be able to throw random .so modules into some directory and tell > Apache::Test to detect them, load them and have have_module() see them. > and Ken really wants to have lots of these directories and point every > time to a different one. So all he does now is generating a simple > extra.conf which only lists LoadModule directives with the correct path > to those modules, A-T picks them up and doesn't require c-modules any > longer (Ken wants to pre-build c-modules for many architectures and many > apache versions). right, I think I got that. but that requires knowing the hard-coded path. perhaps I wasn't clear enough, but the proposed httpd.extra.conf.in would be appended to the generated httpd.conf rather than pulled in via Include. would that not suit the needs that the current patch resolves? > > I like this Ken's new option because it'll suite cases where a user > can't modify the global httpd.conf, but will be able to add its own > global httpd.conf extra's via this option. We have also discussed to > make it accept more than one file, but at the moment it's not possible > and will require quite a few changes (currently config is a hash and > it's set in more than one place). doable, but we probably shouldn't > touch it until someone will really need it. would there really be a need to pull in more than one config into the main httpd.conf that couldn't be met via Include? > > While we discussed possible solutions, I suggested an idea to figure out > whether we have a compiler at all, and if not skip even trying to build > c-modules. So if you build things on machine A with a compiler and then > tar things up and move it to machine B w/o a compiler (same > architecture), the modules will be already precompiled and ready to use > and t/TEST -clean won't nuke them. Ken said that this idea didn't suite > him, but I think it could be useful to others. The kludge is how to > figure out whether things will be able to compile or not (whether there > is a compiler at all). yes, it's a separate issue but a good idea as well. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
Geoffrey Young wrote: [EMAIL PROTECTED] wrote: coar2004/04/01 15:57:17 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm Log: add an '-httpd_conf_extra ' option to allow an *additional* server config file to be inherited as well as the server's main one (or one specified with -httpd_conf). ok, I guess you guys figured out how to do it :) Looks like Ken's hair started to grow again, after he had it all lost over this case :) anyway, if I can interject a few comments on the idea... we already have a few files that get magical treatment: extra.conf.in, extra.last.conf.in, modperl_startup.pl, etc. I think the way I would do it (from afar :) is to create yet another special case, maybe httpd.extra.conf.in or somesuch. advantages would be that it would follow the approach we've been using, it wouldn't require an extra runtime argument, and it could benefit from variable subsitution like all the other conf files. That probably won't suite Ken's particular need. What Ken was after is to be able to throw random .so modules into some directory and tell Apache::Test to detect them, load them and have have_module() see them. and Ken really wants to have lots of these directories and point every time to a different one. So all he does now is generating a simple extra.conf which only lists LoadModule directives with the correct path to those modules, A-T picks them up and doesn't require c-modules any longer (Ken wants to pre-build c-modules for many architectures and many apache versions). I like this Ken's new option because it'll suite cases where a user can't modify the global httpd.conf, but will be able to add its own global httpd.conf extra's via this option. We have also discussed to make it accept more than one file, but at the moment it's not possible and will require quite a few changes (currently config is a hash and it's set in more than one place). doable, but we probably shouldn't touch it until someone will really need it. While we discussed possible solutions, I suggested an idea to figure out whether we have a compiler at all, and if not skip even trying to build c-modules. So if you build things on machine A with a compiler and then tar things up and move it to machine B w/o a compiler (same architecture), the modules will be already precompiled and ready to use and t/TEST -clean won't nuke them. Ken said that this idea didn't suite him, but I think it could be useful to others. The kludge is how to figure out whether things will be able to compile or not (whether there is a compiler at all). __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
[EMAIL PROTECTED] wrote: > coar2004/04/01 15:57:17 > > Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm > TestConfigParse.pm > Log: > add an '-httpd_conf_extra ' option to allow > an *additional* server config file to be inherited as > well as the server's main one (or one specified with > -httpd_conf). ok, I guess you guys figured out how to do it :) anyway, if I can interject a few comments on the idea... we already have a few files that get magical treatment: extra.conf.in, extra.last.conf.in, modperl_startup.pl, etc. I think the way I would do it (from afar :) is to create yet another special case, maybe httpd.extra.conf.in or somesuch. advantages would be that it would follow the approach we've been using, it wouldn't require an extra runtime argument, and it could benefit from variable subsitution like all the other conf files. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Doug MacEachern wrote:
> On Thu, 6 Sep 2001, Gary Benson wrote:
>
> > > +# untaint
> > > +$ENV{PATH} = '/bin:/usr/bin';
>
> this should be 'local $ENV{PATH} = ...;', does that help at all?
oops, I've missed the point that you were explicitly set PATH:
% export PATH=/path/to/httpd-and-apxs:$PATH
so I was ruining it. So would the empty path will be OK?
local $ENV{PATH} = '';
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Doug MacEachern wrote:
> On Thu, 6 Sep 2001, Gary Benson wrote:
>
> > > +# untaint
> > > +$ENV{PATH} = '/bin:/usr/bin';
>
> this should be 'local $ENV{PATH} = ...;', does that help at all?
Yeah, that fixed it.
Gary
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Gary Benson wrote:
> > +# untaint
> > +$ENV{PATH} = '/bin:/usr/bin';
this should be 'local $ENV{PATH} = ...;', does that help at all?
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
> > > This breaks on mine even though $httpd is an absolute path at this point.
> >
> > You mean if you don't add the patch from above?
>
> >From a clean, current CVS checkout:
BTW, be aware of the HEAD httpd-2.0, somebody has broken the source file
used by httpd-2.0, nothing will work if you update this build.
> % cd httpd-test/perl-framework
> % export PATH=/path/to/httpd-and-apxs:$PATH
> % perl Makefile.PL
> % make
> % t/TEST -start-httpd
> setting ulimit to allow core files
> ulimit -c unlimited
> exec t/TEST -start-httpd
> cannot build c-modules without apxs
> no test server configured, please specify an httpd or apxs or put either in
> your PATH
That's because you have to configure it:
perl Makefile.PL apxs /path/to/httpd/bin/apxs
I think README says that. Or you should run:
t/TEST httpd /path/to/apache/bin/httpd -start
> > > I'm not familiar enough with Perl to know why this should be, but is there
> > > a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
> > > Would that successfully untaint it?
> >
> > It's not about being absolute path or not, it's about opening "-|", which
> > is insecure if $ENV{PATH} is not untainted.
>
> I don't really think I understand this line:
>
> |open my $v, '-|', $cmd or die "$cmd failed: $!";
>
> As far as I see it, '-|' means perform an explicit fork, with return
> value of open being child pid in the parent and 0 in the child. From what
> I see, it looks like you should be doing either of these two:
>
> |open my $v, "$httpd|" or die "$cmd failed: $!";
that's the triple args open which is safer than two args open. It's the
same as:
open my $v, "$httpd|" or die "$cmd failed: $!";
See the output of:
% perldoc -f open
If the filename begins with "'|'", the filename is
interpreted as a command to which output is to be
piped, and if the filename ends with a "'|'", the
filename is interpreted as a command which pipes
output to us. See the Using open() for IPC entry
in the perlipc manpage for more examples of this.
(You are not allowed to "open" to a command that
pipes both in and out, but see the IPC::Open2
manpage, the IPC::Open3 manpage, and the
Bidirectional Communication with Another Process
entry in the perlipc manpage for alternatives.)
If MODE is "'|-'", the filename is interpreted as
a command to which output is to be piped, and if
MODE is "'-|'", the filename is interpreted as a
command which pipes output to us. In the
> |open my $v, '-|' or exec $httpd or die "$cmd failed: $!";
>
> I'm not saying that your code is _wrong_: I'm saying I don't understand
> it. I can see what your line does, but now how it does it or why '-|' is
> insecure.
whenever '|' is used in the open() call, $ENV{PATH} and a few other env
vars have to be untainted. See the perlsec manpage.
the triple args open() is safer than double, becase the latter invokes
shell and then one can try to slide in something like "filename; rm -rf
/", whereas with the former the sysopen() is used instead and no shell
interpretation problems happen.
> > > I can't tell, since mine doesn't complain about it being tainted at this
> > > point and I can't figure out a way to make it do so. Why do you need to
> > > untaint here anyway? Is this something from mod_perl? I'm confused!
> >
> > What's your Perl version? perl -v ?
>
> v5.6.1
just almost like me. I'm running 5.7.1
> I'm just running it as my UID, so would taint checking happen anyway?
Yup. Don't confuse taint problems with setuid problems. Taint things are
the same no matter what your UID is.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Stas Bekman wrote:
> On Thu, 6 Sep 2001, Gary Benson wrote:
>
> >
> > On 6 Sep 2001 [EMAIL PROTECTED] wrote:
> >
> > > stas01/09/05 19:36:44
> > >
> > > Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
> > > TestConfigParse.pm
> > > Log:
> > > - enable taint mode in tests via PerlSwitches -T
> > > - untaint $ENV{PATH} before using open "-|"
> >
> > [snip]
> >
> > > diff -u -r1.7 -r1.8
> > > --- TestConfigParse.pm 2001/08/20 15:20:50 1.7
> > > +++ TestConfigParse.pm 2001/09/06 02:36:44 1.8
> > > @@ -220,6 +220,8 @@
> > >
> > >my $version;
> > >my $cmd = "$httpd -v";
> > > +# untaint
> > > +$ENV{PATH} = '/bin:/usr/bin';
> > >open my $v, '-|', $cmd or die "$cmd failed: $!";
> > >
> > >local $_;
> >
> > This breaks on mine even though $httpd is an absolute path at this point.
>
> You mean if you don't add the patch from above?
>From a clean, current CVS checkout:
% cd httpd-test/perl-framework
% export PATH=/path/to/httpd-and-apxs:$PATH
% perl Makefile.PL
% make
% t/TEST -start-httpd
setting ulimit to allow core files
ulimit -c unlimited
exec t/TEST -start-httpd
cannot build c-modules without apxs
no test server configured, please specify an httpd or apxs or put either in
your PATH
> > I'm not familiar enough with Perl to know why this should be, but is there
> > a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
> > Would that successfully untaint it?
>
> It's not about being absolute path or not, it's about opening "-|", which
> is insecure if $ENV{PATH} is not untainted.
I don't really think I understand this line:
|open my $v, '-|', $cmd or die "$cmd failed: $!";
As far as I see it, '-|' means perform an explicit fork, with return
value of open being child pid in the parent and 0 in the child. From what
I see, it looks like you should be doing either of these two:
|open my $v, "$httpd|" or die "$cmd failed: $!";
|open my $v, '-|' or exec $httpd or die "$cmd failed: $!";
I'm not saying that your code is _wrong_: I'm saying I don't understand
it. I can see what your line does, but now how it does it or why '-|' is
insecure.
> > I can't tell, since mine doesn't complain about it being tainted at this
> > point and I can't figure out a way to make it do so. Why do you need to
> > untaint here anyway? Is this something from mod_perl? I'm confused!
>
> What's your Perl version? perl -v ?
v5.6.1
I'm just running it as my UID, so would taint checking happen anyway?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Gary Benson wrote:
>
> On 6 Sep 2001 [EMAIL PROTECTED] wrote:
>
> > stas01/09/05 19:36:44
> >
> > Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
> > TestConfigParse.pm
> > Log:
> > - enable taint mode in tests via PerlSwitches -T
> > - untaint $ENV{PATH} before using open "-|"
>
> [snip]
>
> > diff -u -r1.7 -r1.8
> > --- TestConfigParse.pm2001/08/20 15:20:50 1.7
> > +++ TestConfigParse.pm2001/09/06 02:36:44 1.8
> > @@ -220,6 +220,8 @@
> >
> >my $version;
> >my $cmd = "$httpd -v";
> > +# untaint
> > +$ENV{PATH} = '/bin:/usr/bin';
> >open my $v, '-|', $cmd or die "$cmd failed: $!";
> >
> >local $_;
>
> This breaks on mine even though $httpd is an absolute path at this point.
You mean if you don't add the patch from above?
> I'm not familiar enough with Perl to know why this should be, but is there
> a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
> Would that successfully untaint it?
It's not about being absolute path or not, it's about opening "-|", which
is insecure if $ENV{PATH} is not untainted.
> I can't tell, since mine doesn't complain about it being tainted at this
> point and I can't figure out a way to make it do so. Why do you need to
> untaint here anyway? Is this something from mod_perl? I'm confused!
What's your Perl version? perl -v ?
It has nothing to do with mod_perl, it's a pure Perl issue (a good one :)
For more information please read the perlsec manpage:
% perldoc perlsec
or as the mod_perl guide suggests:
http://perl.apache.org/guide/help.html#Get_help_with_Perl_CGI:
http://www.gunther.web66.com/FAQS/taintmode.html
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Barrie Slaymaker wrote:
> On Thu, Sep 06, 2001 at 12:33:43PM +0100, Gary Benson wrote:
> >
> > > +$ENV{PATH} = '/bin:/usr/bin';
>
> Hmmm, just noticed this in the reply. On Win32, the PATH sep is ';'
> (assuming that you want this code to work there, don't know).
Oops, portability issue. How about:
$ENV{PATH} = ''; We use full paths anyway.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, Sep 06, 2001 at 12:33:43PM +0100, Gary Benson wrote:
>
> > +$ENV{PATH} = '/bin:/usr/bin';
Hmmm, just noticed this in the reply. On Win32, the PATH sep is ';'
(assuming that you want this code to work there, don't know).
Don't know about the taint issues.
- Barrie
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On 6 Sep 2001 [EMAIL PROTECTED] wrote:
> stas01/09/05 19:36:44
>
> Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
> TestConfigParse.pm
> Log:
> - enable taint mode in tests via PerlSwitches -T
> - untaint $ENV{PATH} before using open "-|"
[snip]
> diff -u -r1.7 -r1.8
> --- TestConfigParse.pm 2001/08/20 15:20:50 1.7
> +++ TestConfigParse.pm 2001/09/06 02:36:44 1.8
> @@ -220,6 +220,8 @@
>
>my $version;
>my $cmd = "$httpd -v";
> +# untaint
> +$ENV{PATH} = '/bin:/usr/bin';
>open my $v, '-|', $cmd or die "$cmd failed: $!";
>
>local $_;
This breaks on mine even though $httpd is an absolute path at this point.
I'm not familiar enough with Perl to know why this should be, but is there
a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
Would that successfully untaint it?
I can't tell, since mine doesn't complain about it being tainted at this
point and I can't figure out a way to make it do so. Why do you need to
untaint here anyway? Is this something from mod_perl? I'm confused!
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Wed, 5 Sep 2001, Doug MacEachern wrote: > On 6 Sep 2001 [EMAIL PROTECTED] wrote: > > > --- TestConfig.pm 2001/09/05 16:41:57 1.51 > > +++ TestConfig.pm 2001/09/06 02:36:44 1.52 > > @@ -940,6 +940,9 @@ > > > >HostnameLookups Off > > > > +# make sure that we test under Taint mode > > +PerlSwitches -T > > + > > wait a sec, i didn't notice the context before. this is the wrong place, > since this generated httpd.conf is being used without modperl. should > instead be in modperl-2.0/t/conf/extra.conf.in (that file will need to be > added to cvs) fixed _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On 6 Sep 2001 [EMAIL PROTECTED] wrote: > --- TestConfig.pm 2001/09/05 16:41:57 1.51 > +++ TestConfig.pm 2001/09/06 02:36:44 1.52 > @@ -940,6 +940,9 @@ > >HostnameLookups Off > > +# make sure that we test under Taint mode > +PerlSwitches -T > + wait a sec, i didn't notice the context before. this is the wrong place, since this generated httpd.conf is being used without modperl. should instead be in modperl-2.0/t/conf/extra.conf.in (that file will need to be added to cvs)
