[GRASSLIST:1278] Re: permissions (continued)

[Roger S. Miller]

On Wed, 13 Dec 2000, Eric G . Miller wrote:
 
> This is an important issue.  I think you're correct in your assessment.
> This seems to be an important issue that should be addressed.

So I tried the changes that I described, and they seem to work.  I can run
grass from other user accounts as long as the user is a member of the the
gis group.  Users who aren't in the gis group can't access the database.  
The users can read existing files and new files are created with useful
permissions.  The test was *very* limited.  No doubt there are some
programs that don't use the library functions that I changed and would
have to be found and edited on a case-by-case basis.

> The other
> place to look is in the g.access command that has hardwired values for
> perms 755 at *best*.

I took a look at g.access.  Changing the default permission makes the
program largely unnecessary.
 
> 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.

I have to admit that the current global lock file seems like a weak ploy.
The global lock file can just be deleted to allow a second user to run
grass simultaneosly. The locks on the monitors seem to work well enough to
avoid conflicts.  Simultaneous access to the same mapset is a much more
demanding task, but a mapset-level lock might be a first step in the right
direction.

> 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.

One issue that came up immediately when I had two users working on one
mapset was that when one user changed the region setting the change
effected both users. I'm sure there are other similar examples -- cases
where the necessary changes require more than different permissions and a
more capable locking system.

I think this is an important issue, but it doesn't seem like an issue for
the 5.0 stable release.  Something more for future releases, I guess.


Roger Miller