[GRASSLIST:1304] Re: permissions (continued)

[Andreas Lange]

Hi Roger,

sorry, but i have currently not the time to discuss this in full detail.
But i suggest that you read the g.mapsets and g.access manual pages. 

The tutorials (sorry again, i have no reference at hand) all point out
that each user has his own mapset and that "permanet", i. e. more or
less static or finished data, should be put to the PERMANENT mapset.
This mapset belongs to the administrator. If a GRASS user has some data
ready that should be accessible by all workgroup members, he could
annonce this and change the mapset permissions with g.access. In order
to see the mapset, the other users have to add the mapset to their
individual search path with g.mapsets. If the data should be made
"permanent", the user must grant access with g.access and the
administrator can copy the data (raster, vector, sites) from within
grass with g.copy. Now the user is free to delete his own copy. 

I think that making the users' mapsets read/write to the whole workgroup
can cause a lot of trouble if the users are not cooperating or are
malicious. And its my expirience that something that can go wrong will
go wrong sooner or later...

Perhaps the people on this list that have more expirience with workgroup
setups could comment on this?


cu,

Andreas

Roger S. Miller wrote:
> 
> 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 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.
> 
> What is map at 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

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