[GRASSLIST:1265] Re: permissions (continued)

[Eric G . Miller]

On Wed, Dec 13, 2000 at 08:42:13PM -0700, 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?
> 
> I will go ahead a study the programming manual (which is downloading as I
> type).  I studied the code a bit and found that I could easily modify the
> G__mapset_permissions code to allow operations if the user has read-write
> access to the mapset.  The second problem I came across was that by
> default grass creates files with rw-r--r-- access, and I need them created
> with rw-rw-r-- access.  I found two places (in gisinit.c and in Init.sh)
> where I can change the umask from 022 to 002. Are there other places where
> I need to make that change? Or better ways to do it?

This is an important issue.  I think you're correct in your assessment.
This seems to be an important issue that should be addressed.  The other
place to look is in the g.access command that has hardwired values for
perms 755 at *best*.  Perhaps GRASS should not try so hard to worry
about permissions and let the filesystem/user worry about it??  I think
g.access could be improved to give the user more control about
read/write access to mapsets.  In conjunction with changes to
G__mapset_permissions(), and maybe removing the GRASS handling of umask
of either 002 or 022, instead taking system settings, a workable
solution can be made.  Also, by setting the GID bit on /home/gis (or
wherever), some of this can be handled.

> And perhaps more importantly, is there any chance that the necessary
> changes could be incorporated in the code - perhaps as an option in
> configure?  Or if I make these changes will I have to maintain those code
> segments myself?
> 
> Oh yeah, I didn't stumble across an answer to my second problem, so I
> still wonder if there are any problems with two user's accessing two
> different mapsets from the same grass installation at the same time.

GRASS still would only allow you to write to the current mapset during
any one session.  Most of the access routines that open files for
writing will only work on the current mapset.  This isn't 100% since a
few modules might have their own file open routines that bypass the
GRASS interface.  There is a method for "locking" files, but I don't
know how often modules make use of it (seems infrequent).  Since the 
"global" lock file for when a session is opened is put in the user's 
home directory, it would be unknown to other users.  Possibly a solution
might involve creating a lock file in a mapset if a session has been
started by a user.  This lock file would "tell" the init scripts that
another user is actively working on a mapset, and would thus deny them
from working *on* it.  However, they could open another mapset and have
read access.  I don't know that this is a great solution, since
different user's may want to work on the same mapset simultaneously, but
may be modifying different data.  A full solution to this issue would
take considerable effort to insure all code is locking/unlocking
resources appropriately.  I'll only note that some unnamed expensive GIS
packages don't handle this scenario very well either.

-- 
Eric G. Miller <egm2 at jps.net>