Menu
▾
▴
nms-cgi-devel
|
From: Nick C. <ni...@cl...> - 2002-01-11 23:40:39
|
On Fri, Jan 11, 2002 at 06:17:21PM -0500, Joseph F. Ryan wrote: > Hmmm, I had originally taken the taint switch off in simple search for that > reason. I wonder how it found its way back in? :) > Now, if only advanced search was up, that problem would have disappeared... > > Perhaps I should update simple search to have better taint handling? Yes, > that's an excellent idea, I think I will! :) > I've got it working, just about. In perl 5.6.0 and above it's easy, just give find() the no_chdir option and the issue vanishes. Before 5.6.0 however there's no no_chdir option as far as I can see, so I've botched it. It might be cleaner to revert to not using File::Find at all if the perl is older than 5.6.0. -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2002-01-13 13:29:28
|
On Fri, 11 Jan 2002, Joseph F. Ryan wrote: > Hmmm, I had originally taken the taint switch off in simple search for that > reason. I wonder how it found its way back in? :) Er, because that isnt the right solution to the problem ;-} I think that the use of -T is stated in the ground rules, if the File::Find that comes with older Perls can't take it then we will have to find something else to use - Is it possible (or indeed desirable ) to wrap the find() in $^T = 0; ... $^T = 1; as long as we are content that everything our code is passing to find() is no longer tainted ? /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Nick C. <ni...@cl...> - 2002-01-13 18:31:06
|
On Sun, Jan 13, 2002 at 01:29:03PM +0000, Jonathan Stowe wrote: > On Fri, 11 Jan 2002, Joseph F. Ryan wrote: > > > Hmmm, I had originally taken the taint switch off in simple search for that > > reason. I wonder how it found its way back in? :) > > Er, because that isnt the right solution to the problem ;-} I think that > the use of -T is stated in the ground rules, if the File::Find that comes > with older Perls can't take it then we will have to find something else to > use - Is it possible (or indeed desirable ) to wrap the find() in $^T = 0; > ... $^T = 1; as long as we are content that everything our code is > passing to find() is no longer tainted ? IMO '$^T = 0;' is a bad, bad thing. I'd much sooner fall back to using readdir. -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2002-01-13 18:50:12
|
On Sun, 13 Jan 2002, Nick Cleaton wrote:
> On Sun, Jan 13, 2002 at 01:29:03PM +0000, Jonathan Stowe wrote:
> > On Fri, 11 Jan 2002, Joseph F. Ryan wrote:
> >
> > > Hmmm, I had originally taken the taint switch off in simple search for that
> > > reason. I wonder how it found its way back in? :)
> >
> > Er, because that isnt the right solution to the problem ;-} I think that
> > the use of -T is stated in the ground rules, if the File::Find that comes
> > with older Perls can't take it then we will have to find something else to
> > use - Is it possible (or indeed desirable ) to wrap the find() in $^T = 0;
> > ... $^T = 1; as long as we are content that everything our code is
> > passing to find() is no longer tainted ?
>
> IMO '$^T = 0;' is a bad, bad thing.
>
But if we already trust all of our inputs ... File::Find is getting
worried because it doesnt believe it can trust the directory names ...
> I'd much sooner fall back to using readdir.
>
We will still have the same problem :)
OK. Then we should do our best to mollify taint as far as File::Find is
concerned, then eval {} the find() and then fall back to our own version
on a $@ ? I have the code for one somewhere I think ...
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Nick C. <ni...@cl...> - 2002-01-13 22:22:59
|
On Sun, Jan 13, 2002 at 06:49:44PM +0000, Jonathan Stowe wrote:
> >
> > IMO '$^T = 0;' is a bad, bad thing.
>
> But if we already trust all of our inputs ... File::Find is getting
> worried because it doesnt believe it can trust the directory names ...
I still don't like turning off taint checking, even for little
bits of the code. It makes me cringe.
> > I'd much sooner fall back to using readdir.
> >
>
> We will still have the same problem :)
If we do the find ourselves using readdir, we can detaint the
return values from readdir and Cwd::cwd() before passing them
to chdir (as File::Find can be made to do in later versions)
or just avoid the issue by not using chdir (like post 5.6
File::Find with the no_chdir option).
> OK. Then we should do our best to mollify taint as far as File::Find is
> concerned, then eval {} the find() and then fall back to our own version
> on a $@ ? I have the code for one somewhere I think ...
That'd work.
--
Nick
|
|
From: Jonathan S. <gel...@ge...> - 2002-01-16 09:15:12
|
On Sun, 13 Jan 2002, Nick Cleaton wrote:
> On Sun, Jan 13, 2002 at 06:49:44PM +0000, Jonathan Stowe wrote:
> > >
> > > IMO '$^T = 0;' is a bad, bad thing.
> >
> > But if we already trust all of our inputs ... File::Find is getting
> > worried because it doesnt believe it can trust the directory names ...
>
> I still don't like turning off taint checking, even for little
> bits of the code. It makes me cringe.
>
> > > I'd much sooner fall back to using readdir.
> > >
> >
> > We will still have the same problem :)
>
> If we do the find ourselves using readdir, we can detaint the
> return values from readdir and Cwd::cwd() before passing them
> to chdir (as File::Find can be made to do in later versions)
> or just avoid the issue by not using chdir (like post 5.6
> File::Find with the no_chdir option).
>
> > OK. Then we should do our best to mollify taint as far as File::Find is
> > concerned, then eval {} the find() and then fall back to our own version
> > on a $@ ? I have the code for one somewhere I think ...
>
> That'd work.
>
I knew there had to be a better solution :
#!/usr/local/old/bin/perl -wT
use subs 'File::Find::chdir';
use File::Find;
$ENV{PATH} = '/bin:/usr/bin:/usr/local/bin';
@ENV{qw(BASH_ENV)} = ('');
find(\&wanted,'.');
sub wanted
{
print $_;
}
sub File::Find::chdir
{
if ( $_[0] =~ m%([^\x00-\x1F]+)% )
{
return CORE::chdir($1);
}
else
{
return undef;
}
}
This had been rattling around in my brain since it first came up but I
never got round to trying it :)
You may or may not disagree with the detainting regex but I will apply
anyway ...
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: iain t. <ic...@eh...> - 2002-01-16 16:15:20
|
* Jonathan Stowe (gel...@ge...) [16 Jan 2002 20:31]:
[...]
> @ENV{qw(BASH_ENV)} = ('');
What's this line for? And what if the shell isn't bash?
cheers,
--
iain. <http://eh.org/~koschei/>
|
|
From: Jonathan S. <gel...@ge...> - 2002-01-16 21:06:17
|
On Thu, 17 Jan 2002, iain truskett wrote:
> * Jonathan Stowe (gel...@ge...) [16 Jan 2002 20:31]:
>
> [...]
> > @ENV{qw(BASH_ENV)} = ('');
>
> What's this line for? And what if the shell isn't bash?
>
Well in taint.c in the perl distribution (bleadperl but I dunno whether
it has changed recently ) you have :
static char* misc_env[] = {
"IFS", /* most shells' inter-field separators */
"CDPATH", /* ksh dain bramage #1 */
"ENV", /* ksh dain bramage #2 */
"BASH_ENV", /* bash dain bramage -- I guess it's contagious */
NULL
};
So, to cut along story short, irrespective of what your OS, shell, and
everything else are if any one of those environment variables are set then
you potentially have a tainting condition, try setting BASH_ENV on windows
for instance :(
The reason I used that idiom when removing the tainted environment
variable was that I couldn't be arsed once I had started with the code to
to determine which of the pesky environment variables I had to get rid of
so I start of assigning a list of a single '' to a hash slice with a
single key - if after I had done that it had come back with complaints
about more variables I would have done :
@ENV{qw(BASH_ENV IFS)} = ('') x 2;
and so forth. However in most of the code you will see $ENV{PATH} being
set to a sensible value and all of the above mentioned variables being set
to the empty string or deleted - certainly with me it depends on the
phases of the moon whether I delete or assign the empty string :)
You can of course delete from a hash slice like:
delete @ENV{qw(BASH_ENV IF ENV)};
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Joseph F. R. <rya...@os...> - 2002-01-16 22:28:36
|
If the subs pragma existed in 5.004 (and, from the /old/ in your path, I
have a feeling it does), this is a brilliant solution. Nice job :)
At 07:30 AM 1/16/2002 +0000, you wrote:
>On Sun, 13 Jan 2002, Nick Cleaton wrote:
>
> > On Sun, Jan 13, 2002 at 06:49:44PM +0000, Jonathan Stowe wrote:
> > > >
> > > > IMO '$^T = 0;' is a bad, bad thing.
> > >
> > > But if we already trust all of our inputs ... File::Find is getting
> > > worried because it doesnt believe it can trust the directory names ...
> >
> > I still don't like turning off taint checking, even for little
> > bits of the code. It makes me cringe.
> >
> > > > I'd much sooner fall back to using readdir.
> > > >
> > >
> > > We will still have the same problem :)
> >
> > If we do the find ourselves using readdir, we can detaint the
> > return values from readdir and Cwd::cwd() before passing them
> > to chdir (as File::Find can be made to do in later versions)
> > or just avoid the issue by not using chdir (like post 5.6
> > File::Find with the no_chdir option).
> >
> > > OK. Then we should do our best to mollify taint as far as File::Find is
> > > concerned, then eval {} the find() and then fall back to our own version
> > > on a $@ ? I have the code for one somewhere I think ...
> >
> > That'd work.
> >
>
>
>I knew there had to be a better solution :
>
>#!/usr/local/old/bin/perl -wT
>
>use subs 'File::Find::chdir';
>use File::Find;
>
>$ENV{PATH} = '/bin:/usr/bin:/usr/local/bin';
>@ENV{qw(BASH_ENV)} = ('');
>find(\&wanted,'.');
>
>sub wanted
>{
> print $_;
>}
>
>sub File::Find::chdir
>{
>
> if ( $_[0] =~ m%([^\x00-\x1F]+)% )
> {
> return CORE::chdir($1);
> }
> else
> {
> return undef;
> }
>}
>
>
>This had been rattling around in my brain since it first came up but I
>never got round to trying it :)
>
>You may or may not disagree with the detainting regex but I will apply
>anyway ...
>
>/J\
>--
>Jonathan Stowe |
><http://www.gellyfish.com> | This space for rent
> |
>
>
>_______________________________________________
>Nms-cgi-devel mailing list
>Nms...@li...
>https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
|
|
From: Jonathan S. <gel...@ge...> - 2002-01-17 09:17:13
|
On Wed, 16 Jan 2002, Joseph F. Ryan wrote: > If the subs pragma existed in 5.004 (and, from the /old/ in your path, I > have a feeling it does), this is a brilliant solution. Nice job :) > Its 5.00404 alright - I even endured pain to build it ;-} /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
Thanks for helping keep SourceForge clean.
X