[Live-demo] Re: [OSGeo] #868: Permissions on GRASS LOCATIONS

[OSGeo]

#868: Permissions on GRASS LOCATIONS
---------------------+------------------------------------------------------
 Reporter:  micha    |       Owner:  live-demo@…                
     Type:  defect   |      Status:  new                        
 Priority:  major    |   Milestone:                             
Component:  LiveDVD  |    Keywords:  QGIS GRASS data permissions
---------------------+------------------------------------------------------

Comment(by hamish):

 > Replying to [comment:3 hamish]:
 > > this is important because it means that it can't be used for
 > > teaching qgis+grass in the classroom setting when the common
 > > source data is over NFS, Samba, or sshfs link; a typical use
 > > case.

 Replying to [comment:4 micha]:
 > Is this use case relevant to the LiveDVD?

 yes, it's specifically intended to be used for quickly seeding a computer
 lab for workshops and tutorials.


 > > I assume qgis gives the permission denied error because it is
 > > trying to write something to the mapset? for a read-only task
 > > what is it trying to open for write and why?
 >
 > Attached are screen shots of the error. Looks like it's failing
 > on setting the region.

 I played around with it a bit more. As far as I can tell to get it to work
 the user must be the owner of the PERMANENT mapset directory, but not any
 files within it. Full write permission is not enough, and AFAICT no files
 are actually written within the dir during the process (the `stat` mtime
 on the directory does not change, which it would if you created then
 removed a temporary .gislock file or so within it). Also I noticed with
 the user owning the PERMANENT/ directory that you could then open read-
 only maps from other mapsets (ie nc/landsat/) just fine. perhaps a glibc
 call to access() is checking for permissions wrongly? (the user must
 actually own the Mapset directory they open, not just have write
 permissions there)

 QGIS should not be changing the region except if the user explicitly runs
 the g.region module; it can use the GRASS_REGION environment variable to
 locally override it without touching the disk. But since no file is
 written to PERMANENT I don't think that's the case (and anyway user1 is
 the open mapset so that should be the one being modified)


 > How about putting the North Carolina and Spearfish datasets right
 > under ~/user/grassdata instead of a symlink to /usr/local/share ??

 It is undesirable to make the disc dependent on the user account, & so far
 we've pretty much managed to make just the desktop setup and some
 superficial program configs rely on the dot files in that account.
 (mysql/postgres DB permissions might be an exception to that)

 Also, wrt my earlier "no go" comment, I've never been 100% clear on this
 but AFAIU for the ISO version it loads /home/user into RAM(?) so there is
 a reason to keep ~user/ just containing very small files. One thing I'm
 not clear on is if that applies to every file `user` explicitly owns or
 just the home dir. The general work around we use is to make the files
 group writable and owned by the "users" group. The ISO-version remakes the
 `user` account at final-build time which wipes the slate clean on a number
 of things.

 I did try copying the grass Locations into ~user/, but the DVD ISO (run in
 a VM) became highly unresponsive after I tried to open some maps. I can't
 say for sure that this was direct causation, but that's the only time I've
 seen that behaviour.


 for now a "just make the darn thing work" end user work-around is a slight
 modification of your earlier suggestion to just change ownership of the
 PERM dir itself:
 {{{
 sudo chown user /usr/local/share/grass/nc_spm_08/PERMANENT
 sudo chown user /usr/local/share/grass/spearfish60/PERMANENT
 }}}

 but as a general solution it is not satisfactory so I wouldn't like to
 include that in the install script. Understanding/fixing the bug in qgis
 may lead to a better work-around in the current version.


 regards,
 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/868#comment:5>
OSGeo <http://www.osgeo.org/>
OSGeo committee and general foundation issue tracker.