[GRASS5] Cannot run GRASS in CGI under nobody account

Glynn Clements glynn.clements at virgin.net
Mon Aug 12 13:36:01 EDT 2002


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 at virgin.net>



More information about the grass-dev mailing list