[GRASSLIST:3359] Allowing multiple users to access a mapset

Hello,

We have a script that starts GRASS for a given location, mapset, and
map, and runs r.profile to find the altitude for a given point.
We would like to allow any user on our system to run the script on a
particular map (non-concurrently). But we've run into problems when
a user that doesn't own the mapset tries to read from it. Does this
mapset
have to be the PERMANENT mapset? Only the owner/admin will be modifying

the map, everyone else would only read from it (assuming that r.profile
only requires reading; is this true?).

We've found some old GRASSlist messages about creating a new mapset
within
the location for each user, but it's not entirely clear to us how to go
about it--what has to be in place for a non-owner to be able to read
from
a mapset. Also, it looks like some people have tried to get around the
ownership issue by disabling the uid checks in G_mapset_permissions.

We would appreciate any help that anyone could give us.

Also there is a question about buffer checking:
    From gisbase.c (admittedly in an old version):

      char msg[100];

      sprintf(msg,_("MAPSET %s - permission denied"), mapset);

  Do you know what the _() around the format string does? Does this
  help with bounds checking?

One last question--
Since we are using only a small part of the GRASS functionality, is
there
some way for us to pare down our GRASS installation so it contains only
the commands we use, and takes up less space?

Thank you,
Peggy Norquist

Peggy Norquist wrote:

We have a script that starts GRASS for a given location, mapset, and
map, and runs r.profile to find the altitude for a given point.
We would like to allow any user on our system to run the script on a
particular map (non-concurrently). But we've run into problems when
a user that doesn't own the mapset tries to read from it. Does this
mapset
have to be the PERMANENT mapset? Only the owner/admin will be modifying
the map, everyone else would only read from it (assuming that r.profile
only requires reading; is this true?).

We've found some old GRASSlist messages about creating a new mapset
within
the location for each user, but it's not entirely clear to us how to go
about it--what has to be in place for a non-owner to be able to read
from
a mapset. Also, it looks like some people have tried to get around the
ownership issue by disabling the uid checks in G_mapset_permissions.

We would appreciate any help that anyone could give us.

A user can read maps from any mapset, provided that they have the
necessary permissions (i.e. read permission on the files and execute
permission on all of the directories in the files' paths).

However, you can't select a particular mapset as the current mapset
(the one where any new maps are stored) unless you own the directory.

Regarding reading maps:

By default, an unqualified map name (with no '@' character) will be
searched for first in the current mapset, and then (if not found
there) in the PERMANENT mapset. The list of mapsets which are searched
can be changed using the g.mapsets command.

Additionally, a user can access a map in another mapset using the
qualified map@mapset form.

Also there is a question about buffer checking:
    From gisbase.c (admittedly in an old version):

      char msg[100];

      sprintf(msg,_("MAPSET %s - permission denied"), mapset);

  Do you know what the _() around the format string does? Does this
  help with bounds checking?

No. the _() macro (it's just a normal C macro whose name is a single
underscore) is used for localisation. It is defined in glocale.h.

One last question--
Since we are using only a small part of the GRASS functionality, is
there
some way for us to pare down our GRASS installation so it contains only
the commands we use, and takes up less space?

You could edit the file src/CMD/lists/GRASS prior to compiling. That
file determines exactly what is compiled and installed. Alternatively,
look at the handheld/babyGRASS_compile.sh script; that is used for
building a minimal GRASS installation for the iPAQ PDA.

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