PERL CGI Beginners - Form mailer and environment variables

Author

Form mailer and environment variables

Jan Eden

2004-05-22, 11:32 am

Hi all,

I wrote a little form mail script and start by setting the environment vari=
ables like this:

BEGIN {
$ENV{PATH} =3D "/usr/sbin";
delete @ENV{ qw( IFS CDPATH ENV BASH_ENV) };
}

Now the actual directory (.) is obviously not searched anymore, since

my $page_head =3D eval do('page_head.pl');

returns an empty $page_head while

my $page_head =3D eval do('./page_head.pl');

fills it with the appropriate content.

Commenting the BEGIN block above and printing $ENV{PATH} gives me:

/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec:/System/Library/CoreServices

I cannot see the current working directory in that list (but I admit that I=
am not used to environment variables at all).

Can someone tell me how to restrict $ENV{PATH} but keep the script's abilit=
y to see something in its own directory?

Thanks,

Jan
--=20
If all else fails read the instructions. - Donald Knuth

Jan Eden

2004-05-22, 11:32 am

Jan Eden wrote on 01.05.2004:

>Hi all,
>
>I wrote a little form mail script and start by setting the
>environment variables like this:
>
>BEGIN {
>$ENV{PATH} =3D "/usr/sbin"; delete @ENV{ qw( IFS CDPATH ENV BASH_ENV)
>};
>}
>
>Now the actual directory (.) is obviously not searched anymore,
>since
>
>my $page_head =3D eval do('page_head.pl');
>
>returns an empty $page_head while
>
>my $page_head =3D eval do('./page_head.pl');
>
>fills it with the appropriate content.
>
>Commenting the BEGIN block above and printing $ENV{PATH} gives me:
>
>/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec:/System/Library/
>/CoreServices
>
>I cannot see the current working directory in that list (but I admit
>that I am not used to environment variables at all).
>
>Can someone tell me how to restrict $ENV{PATH} but keep the script's
>ability to see something in its own directory?

Please let me add that I did try to set $ENV{PATH} =3D ".:/usr/sbin".

That did not work either.

- Jan
--=20
The day Microsoft makes something that doesn't suck is the day they start s=
elling vacuum cleaners.

Paul Archer

2004-05-22, 11:32 am

Tomorrow, Jan Eden wrote:

> Hi all,
>
> I wrote a little form mail script and start by setting the environment variables like this:
>
> BEGIN {
> $ENV{PATH} = "/usr/sbin";
> delete @ENV{ qw( IFS CDPATH ENV BASH_ENV) };
> }
>
Why are you deleting these variables?

> Now the actual directory (.) is obviously not searched anymore, since
>
> my $page_head = eval do('page_head.pl');
>
> returns an empty $page_head while
>
> my $page_head = eval do('./page_head.pl');
>
> fills it with the appropriate content.
>
> Commenting the BEGIN block above and printing $ENV{PATH} gives me:
>
> /bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec:/System/Library/CoreServices
>
> I cannot see the current working directory in that list (but I admit that I am not used to environment variables at all).
>
> Can someone tell me how to restrict $ENV{PATH} but keep the script's ability to see something in its own directory?
>
What OS, shell, and version of Perl are you using? On Linux with bash, and
running Perl 5.8.0, I can't reproduce this.

Paul

Wiggins D'Anconia

2004-05-22, 11:32 am

Jan Eden wrote:
> Hi all,
>
> I wrote a little form mail script and start by setting the environment variables like this:
>
> BEGIN {
> $ENV{PATH} = "/usr/sbin";
> delete @ENV{ qw( IFS CDPATH ENV BASH_ENV) };
> }
>
> Now the actual directory (.) is obviously not searched anymore, since
>
> my $page_head = eval do('page_head.pl');
>
> returns an empty $page_head while
>
> my $page_head = eval do('./page_head.pl');
>
> fills it with the appropriate content.
>
> Commenting the BEGIN block above and printing $ENV{PATH} gives me:
>
> /bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec:/System/Library/CoreServices
>
> I cannot see the current working directory in that list (but I admit that I am not used to environment variables at all).
>
> Can someone tell me how to restrict $ENV{PATH} but keep the script's ability to see something in its own directory?
>

The current working directory and the script's own directory are
different things.

perldoc Cwd
perldoc FindBin

Does,

use FindBin qw($Bin);

my $page_head = eval do($Bin . '/page_head.pl');

Get you where you are going?

Out of curiousity what's with the 'eval do' stuff? What are you really
trying to do?

http://danconia.org

Jan Eden

2004-05-22, 11:32 am

Wiggins d'Anconia wrote on 30.04.2004:

>Jan Eden wrote:
>
>The current working directory and the script's own directory are
>different things.
>
Yes. I meant the script's own directory.

>perldoc Cwd perldoc FindBin
>
>Does,
>
>use FindBin qw($Bin);
>
>my $page_head =3D eval do($Bin . '/page_head.pl');
>
>Get you where you are going?
>
Not exactly. Let me explain.

>Out of curiousity what's with the 'eval do' stuff? What are you
>really trying to do?

The 'eval do' combination is a neat trick Rob Dixon suggested: I have a pi=
ece of html code containing some perl variables in page_head.pl / page_foot=
=2Epl.

To evaluate the content of a file, 'do' is the easiest way. But code evalua=
ted with 'do' does not see variables in the enclosing scope. So Rob suggest=
ed the following construction:

q{ qq{ #code with variables here# } };

When 'do' evaluates this, it returns

qq{ #code with variables here# }

If I apply this as an argument to 'eval', the variables are interploated in=
the context of the current script. Neat.

But now I decided to use a more Perl style solution, namely building a simp=
le module which contains a subroutine 'headfoot'. This subroutine should ta=
ke the variables occurring in the page head/foot as arguments and return th=
e page head/foot with the values inserted, like

sub headfoot {
my ($id, $mode, $mother_title) =3D shift;
my $page_head =3D "html html $mode html html $mother_title html $id";
return $page_head;
}

Since I do not have access to the Perl installed on my server, I can only u=
se modules in the directory I store my own scripts in. When not manipulatin=
g the environment variables, this is not a problem.

But when setting $ENV{PATH} like above, the script's own directory is not s=
earched (as the failure of do('page_head.pl') shows). When using a module, =
though, I cannot say

use ./Module

as I can do with 'do' (as in do('./page_head.pl')). So the upshot is: I wan=
t to set $ENV{PATH} to make the form mail script more secure, but I want to=
include the script's own directory (in a principled way, not as an absolut=
e path on my machine) in $ENV{PATH}.

$ENV{PATH} =3D ".:/usr/sbin";

did not do what I want.

Sorry for the extensive post.

Thanks,

Jan
--=20
Common sense is what tells you that the world is flat.

Jan Eden

2004-05-22, 11:32 am

Paul Archer wrote on 30.04.2004:

>Tomorrow, Jan Eden wrote:
>
>Why are you deleting these variables?
>
Security. I read that restricting the environment variables makes some hack=
er tasks more difficult.
>
>What OS, shell, and version of Perl are you using? On Linux with
>bash, and running Perl 5.8.0, I can't reproduce this.
>

Mac OS 10.3.3, bash, 5.8.1.

Thanks,

Jan
--=20
These are my principles and if you don't like them... well, I have others. =
- Groucho Marx

Jan Eden

2004-05-22, 11:32 am

Hi guys,

I think I found the exact source to my problem: it's the taint mode, as alw=
ays. From CGI Programming:

@INC will not include the current working directory. If your script needs t=
o require or use other Perl code in the current directory, you must explici=
tly add the current directory to @INC ...

Well, I tried that, using a BEGIN block like:

BEGIN {
push @INC, ('.');
$ENV{PATH} =3D "/usr/sbin";
delete @ENV{ qw( IFS CDPATH ENV BASH_ENV) };
}

That did the trick! Thanks for your help!

BTW, p. 210 of CGI Programming also mentions why deleting certain environme=
nt variables is a good thing to do (in addition to using taint mode).

- Jan
--=20
Common sense is what tells you that the world is flat.

Sponsored Links