[GRASS5] Cannot run GRASS in CGI under nobody account

GRASS GRASS developer
1

Good afternoon, everyone,

I'm trying to use CGI to dynamically post GIF maps processed by GRASS to
the webpage. I'm doing this in Linux using Perl and Shell programming
languages.

The basic idea is that in my CGI-Perl program, I try to start GRASS
(grass5) to create a GIF map, and then copy the map to Apache2 'icons'
directory. By doing this, it should be able to show the map online.

I can do this in my own Linux account. I can see this (in text in X
windows) by directly executing the CGI-Perl program.

However, I cannot see it by only using browser to trigger the program. I
was told that to test this, I need to use 'nobody' account. When I changed
to nobody account, I found the CGI-Perl program really doesnot work.

The error message I got is as follows.

bash$ grass5
/usr/local/grass5/etc/lock: //.gislock5: Permission denied
Unable to properly access //.gislock5
Please notify system personel.
bash$ exit

Could anybody help me for this problem? Thank you very much for your help
in advance.

Ping

2

The answer may be the following:
check if apache runs as 'nobody';
if really so check permissions on your install grass
directory
to see if the write permissions for nobody are there.

SY,

--alex

--- Ping Liu <pingl@hawaii.edu> wrote:

Good afternoon, everyone,

I'm trying to use CGI to dynamically post GIF maps
processed by GRASS to
the webpage. I'm doing this in Linux using Perl and
Shell programming
languages.

The basic idea is that in my CGI-Perl program, I try
to start GRASS
(grass5) to create a GIF map, and then copy the map
to Apache2 'icons'
directory. By doing this, it should be able to show
the map online.

I can do this in my own Linux account. I can see
this (in text in X
windows) by directly executing the CGI-Perl program.

However, I cannot see it by only using browser to
trigger the program. I
was told that to test this, I need to use 'nobody'
account. When I changed
to nobody account, I found the CGI-Perl program
really doesnot work.

The error message I got is as follows.

bash$ grass5
/usr/local/grass5/etc/lock: //.gislock5: Permission
denied
Unable to properly access //.gislock5
Please notify system personel.
bash$ exit

Could anybody help me for this problem? Thank you
very much for your help
in advance.

Ping

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

3

Ping Liu wrote:

I'm trying to use CGI to dynamically post GIF maps processed by GRASS to
the webpage. I'm doing this in Linux using Perl and Shell programming
languages.

The basic idea is that in my CGI-Perl program, I try to start GRASS
(grass5) to create a GIF map, and then copy the map to Apache2 'icons'
directory. By doing this, it should be able to show the map online.

I can do this in my own Linux account. I can see this (in text in X
windows) by directly executing the CGI-Perl program.

However, I cannot see it by only using browser to trigger the program. I
was told that to test this, I need to use 'nobody' account. When I changed
to nobody account, I found the CGI-Perl program really doesnot work.

The error message I got is as follows.

bash$ grass5
/usr/local/grass5/etc/lock: //.gislock5: Permission denied
Unable to properly access //.gislock5
Please notify system personel.
bash$ exit

This indicates that nobody's home directory is "/" (the root
directory); the nobody account almost certainly doesn't have write
permission on this directory. GRASS needs to be able to write to the
directory which is specified by $HOME.

A couple of points:

1. Apache shouldn't run as "nobody", but using its own dedicated
account. The "nobody" account is supposed to have absolutely minimal
permissions. On some operating systems (but not Linux), the kernel
treats "nobody" specially, explicitly rejecting operations which would
otherwise succeed.

2. You might be able to work around the problem by explicitly setting
HOME in your script, e.g.

  HOME=/tmp/grass-cgi
  export HOME

3. Be very, very careful about validating the data which you pass to
GRASS programs from the HTTP request. Most GRASS programs (and the
underlying libraries) don't perform any validation on their inputs;
they rely upon it being correct.

There are many fixed-size buffers which could be overflowed, and calls
to system() which include caller-supplied text verbatim. If you don't
validate the input, your CGI script will provide users with a remote
command execution facility.

Unless you have a good understanding of CGI security issues, or the
script will only be accessible by trusted users, I suggest that you
don't use GRASS in this way.

--
Glynn Clements <glynn.clements@virgin.net>