Thanks, Andrea. Unfortunately my response and questions below became
rather long.
On Sat, 16 Dec 2000, Andreas Lange wrote:
it may be that i misunderstand what you said. But i think the correct
setup is as follows:
create a data directory onwned by a special GRASS GIS user (e. g. grass)
and owned by a special gis users group (e. g. gis). The directory
permissions must be set so that every user of the gis group is allowed
to create new directories (rwxrwxr-x). Every user that wants to work
with GRASS must do a "newgrp gis" before starting the work. Then every
user must create her/his own mapset ("andreas", "username") to work
within.
The version of newgrp that I have (a GNU product, I think) seems to be
broken. When I use it to change groups it also clears my $HOME
environment variable and that makes it impossible to start grass.
Fortunately it doesn't appear necessary to use newgrp on Linux; merely
being listed as a member of the group (at least, a group without a
password) is sufficient to provide group-level access.
My employer likes separating the data files from different projects, which
in practice means having a different dataset for each project. In the few
projects I've used grass on so far the data have come in two or more
different projections, requiring two or more different locations for each
project. So with three simultaneous projects, two projections used in
each project and three people using the GIS each with their own mapsets,
we would need to create and maintain 18 different mapsets, several of
which would be duplicative. That's the kind of complexity I'd like to
avoid.
If the user wants to process existing data, the user can either
use map@PERMANENT or use g.copy or r.mapcalc new=map@PERMANENT to create
his own copy of the map. If the results of the analysis should be made
accessible to everyone in the group, the files must be copied by the
owner of the PERMANENT mapset (the gis administrator) to PERMANENT. Or
the access must be changed with g.access to provide access to the users
mapset.
What is map@PERMANENT? This isn't a command syntax I've run across yet.
I ran across a reference in the archive to using the PERMANENT mapset as a
location for transferring files. I tried that and was unable to get
access to PERMANENT without being the owner of the mapset. Reading the
code I couldn't find how PERMANENT had access requirements different from
any other mapset. That is, you have to be the owner of the mapset in order
to access it. Do I have something wrong here?
I haven't tried using g.copy between mapsets, does it defeat the mapset
permissions requirements?
As near as I can tell, g.access will give filesystem-level read access
on a file, but it doesn't alter mapset permissions. The file would have
to be copied out of it's original mapset by the mapset's owner.
Some time ago i tried to figure out the correct permissions for all the
example data sets, but i have the file not at hand right now.
I think that generally in a workgroup environment a lot of
organizational work is needed to keep the data in sync. As GRASS
provides no means of versioning or atomic locking of the data i think
that the setup outlined above is not optimal, but works.
Some supervisory work is usually necessary, but it seems like I should be
able to reduce the time required. What I have done is:
1. Create a home directory for the owner of the gis and copy the existing
data sets to subdirectories under the owner's home. I set the permission
on everything in the data sets to provide read and write access to
everyone in the gis group. Probably that group should be password
protected. This is very much along the lines you suggested.
2. Altered the code that checks mapset permissions so that it allows
access to a mapset if the filesystem security allows such access. In this
case it means that everyone in the gis group has read/write access to all
the data in all of the mapsets. It also allows the gis administrator or
the superuser to use grass to help with supervisory jobs, rather than
having to do them in the UNIX shell because of the restrictive permissions
imposed by grass.
3. Changed the umask specified at several points in the code from 022 to
002, so that new files would be created with group read/write permissions.
This is the most iffy of all the changes I made. It probably isn't
sufficient.
4. Moved the locking code in the Init program so that the lock file is
created after the user's database/location/mapset is specified and changed
the code to use a lock file in the mapset rather than in the user's home
directory. That gives a mapset-level lock and allows multiple users to
run grass concurrently. This was a very simple change and I don't see any
down side to doing it. I'm contemplating changing permissions on the lock
files so that the locks can only be removed by su, by the gis
administrator or by a program running under the administrator's uid.
I'm perfectly willing to send the changes back to the code builders if
they would like to see them.
These changes allow a workgroup to use the same database structure that a
single user would use, allows concurrent use of grass and provides for
supervisory access to the databases through grass. The changes don't allow
concurrent access to a mapset, which would be a good thing to have.
As Eric pointed out, grass does have a file-locking capability that seems
to be mostly unused. I don't know why it isn't used. There appear to be
a couple ways to get file locking, so file locking doesn't look like the
worst of the problems. A worse problem might be with settings like the
region or color table selection.
Thanks for your response,
Roger Miller
Lee Wilson and Associates