A stupid question...

[Linda Moet]

> > 2)  In order for a web user to access a mapset, they must own it.  (There
> > was a discussion on the list a short while ago about sharing mapsets and why
> > it isn't possible - only the owner of a mapset can access it.)
> 
> More precisely, in order for a user to execute any Grass command, they must
> possess their own mapset. This is actually an unnecessary restriction in those
> cases where users simply want read-only access to some common dataset. Most d.*
> and g.* commands, for example, do not write anything to the mapset, and this
> tends to be the province of r.* commands. There would be some merit in
> re-programming Grass so that individual mapsets are only constructed upon
> demand. This would require some minor tinkering around with the gis libraries,
> and would involve making Grass store the user's WIND in an alternative location
> (like .grassrc). Another possible extension for the enthusiast would be to make
> Grass write to the client rather than to the server.


Of course you are right.  Thanks for clarifying.  As I mentioned in my
original post, I have made a lot of mistakes, and tinkering with mapsets
was one of them.  Even though my sample CGI script did nothing but
return the output of the g.list command for raster files in the
spearfish location (a read-only operation, as you mention), I got the
following errors when I set the MAPSET to:

1) (nothing at all)
  ERROR: MAPSET not set

2)  lindam (even with permissions set to 777!)
  ERROR: MAPSET lindam - permission denied

3)  PERMANENT
  ERROR: MAPSET PERMANENT - permission denied

4)  wwwgrass (owned by user nobody)
  No errors - this works!

Your suggestions make a lot of sense for applications where there would
be users who only query the GIS, not modify it (GRASS-on-the-Web being a
prime example).  Maybe someday I will acquire enough programming
know-how to contribute to the effort.  =+)

-Linda