[GRASSLIST:1287] Re: permissions (continued)

[Andreas Lange]

Roger S. Miller wrote:
> 
> Folks,
> 
> I earlier posted a couple questions about problems getting the right
> permissions on my grass 5beta10 installation.  Hopefully no one wasted too
> much time answering my questions.
> 
> My startup problem -- with the init program apparently trying to create a
> lock file in / -- was fairly easy to figure out.  It actually was trying
> to create the file $HOME/.gislock5.  Apparently the "newgrp" command
> clears the $HOME environment variable.  I used newgrp to switch to the gis
> group, then started grass.  $HOME was null when I started grass so it
> tried opening the lock file as /.gislock5.  Not great behavior, but not a
> serious problem either.
> 
> A somewhat more serious problem (to me, anyway) is that it appears
> impossible to run grass in a workgroup environment.  Grass requires that
> the user ID associated with the mapset must be the same as both the real
> and effective uid of the process.
> 
> Is there any way around the restrictions?
> 

Hi Roger, Hi Eric,

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. If the user wants to process existing data, the user can either
use map at PERMANENT or use g.copy or r.mapcalc new=map at 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. 

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. 

cu,

Andreas

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net