PERL Beginners - Cgi with GD grap, and displaying graphs

Author

Cgi with GD grap, and displaying graphs

Patrick Rice

2006-08-29, 9:57 pm

Hi all

I'd like some advice,
set up; Red hat Enterprise 4
Perl 5.8

I am trying to create a web page, which takes data from a file and
builds a graph with GD, these are then saved as pictures, I then use the
cgi script to call the pics using dynamically generated HTML page, using
a system call to another perl script.

When I do this, I get a 500 internal error and I've traced this down to
a permissions problem, as the apache user doesn't have the permissions
to write the pic's in the /var/www/html file.

When I run the perl script from /var/www/cgi-bin, as root no prob
righting the pics in /var/www/html, but apache user doesn't have
permissions.

I am wondering what is wrong, and am I doing this the right way, should
I get GD to display the graph with in the perl script and not right
pic's but dynamically display them, rather than calling another script
to display the HTML, using system "html_diplay.pl", essentially two
scripts instead of one.

Thanks in advance for the help.

Pat

Tom Phoenix

2006-08-29, 9:57 pm

On 8/29/06, Patrick Rice <patrick.j.rice@gmail.com> wrote:

> When I do this, I get a 500 internal error and I've traced this down to
> a permissions problem, as the apache user doesn't have the permissions
> to write the pic's in the /var/www/html file.

Which is as it should be, I would imagine.

For security purposes, I generally see three categories of files the
webserver can access:

* servable files - like web pages and images (serve, never run, never write)
* programs - executable code (run, never serve, never write)
* data files - (read and write, never serve, never run)

If you keep these organized by directories, the server has an easy
time enforcing the security rules. If it's somebody else's webserver,
they probably use roughly the same security categories.

Even though the server won't directly serve the data files, you can
easily make a CGI program that does little more than read and output
the requested file. The PATH_INFO can be quite useful here, but use
caution not to trust it without checking, because it's supplied by the
user. But this URL could lead your program to serve the data file
found in (some directory) maps/portugal/2006.png :

http://www.example.com/cgi-bin/virt...rtugal/2006.png

That CGI program is not the only solution. You could add a fourth
category, for example:

* servable data files - (read, write, or serve, never run)

You could use Apache's Alias directive to set this up, something like this:

Alias /servdata /home/fred/webdata

Now, when the server gets a request like this:

http://www.example.com/servdata/maps/portugal/2006.png

It knows which file to serve:

/home/fred/webdata/maps/portugal/2006.png

If you choose this route, there are some additional security issues.
For example, if it were my apache webserver, I'd configure it to
ignore (or at least restrict) any .htaccess files found in the
server-writable directories. And I'd probably not allow browsing in
these directories, either.

But I'd probably choose the CGI program, since it's simple to secure
and not likely to be a significant amount of overhead.

Hope this helps!

--Tom Phoenix
Stonehenge Perl Training

Mumia W.

2006-08-29, 9:57 pm

On 08/29/2006 11:05 AM, Patrick Rice wrote:
> Hi all
>
> I'd like some advice,
> set up; Red hat Enterprise 4
> Perl 5.8
>
>
> I am trying to create a web page, which takes data from a file and
> builds a graph with GD, these are then saved as pictures, I then use the
> cgi script to call the pics using dynamically generated HTML page, using
> a system call to another perl script.
>
> When I do this, I get a 500 internal error and I've traced this down to
> a permissions problem, as the apache user doesn't have the permissions
> to write the pic's in the /var/www/html file.
> [...]

Perhaps you could create a directory, /var/www/cgi-img/, and
make sure that the web-server can write in that directory and
change your script to write in that directory.

Since you are using RHEL, you should also make sure that
SELinux is not interfering with Apache.

Sponsored Links