GRASS plugin mapset permission blocks use if user doesn't own PERMANENT

[qgib]

Author Name: hamish - (hamish -)
Original Redmine Issue: 2947
Affected QGIS version: 1.8.0
Redmine category:grass

---

[fwd from the live-demo@osgeo list, where it breaks the QGIS-GRASS plugin completely] :-(

Massimo Di Stefano wrote:

Download a new spearfish.tar.gz in the download directory

(better: just copy -r from /usr/local/share/...)

and tring to load grass file from qgis opening this "new"
spearfish directory
i have no problem to dispay grass data inside qgis.

I get the same. (see comments in my 4.0rc6 error summary from
some days ago where I cover this)

hence, it is a permision problem in the grass locations

exec summary:
the problem is a bug in qgis 1.5.0 [...]. I don't think we can work around it for this release of the live DVD and the best solution for now is to add a note in the qgis quickstart that you should copy the spearfish dataset to the home dir before starting if you want to use the grass toolbox. [n.b. to date we have no qgis quickstart!]

longer version:
GRASS was designed to be (optionally) used on a server/mainframe
by a team/class all working on the same project, with the data
held on the central server or mounted via NFS. (this is why the
spearfish dataset's working mapset is called "user1" btw)
To avoid mass confusion you may only write to your own mapsets,
but you may read from (and include in your map search path) any
of your teammates mapsets, and everyone on the team can read
from the PERMANENT mapset which typically holds core base maps.
The team leader controls the PERMANENT mapset. Individual users
can also make their own mapsets public or private via the
g.access module if they like. For many years it has been like
this, all(?) bugs squashed long ago, and all has been well.
(of course on the Windows build UAC is a total mess, but that's
not really our fault)

So the rule is that your user account must own the mapset in
the filesystem in order to make that the current one. and that's
the way GRASS is set up on the livedvd, with an empty skeleton
mapset in /home/, and read-only data mapsets owned by root.

QGIS is respecting this, but it is taking it too far enforcing
that the PERMANENT mapset must be owned by the user too. or
maybe it is trying to temporarily open the PERMANENT mapset even
if you didn't request it? (eg to grab the common map projection
info)

Hamish

ps- rpy2 addition may now fix habitat plugin removed in the livedvd install script. pls check

---

• GRASS_plugin_error.png (Micha Silver)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• fixed_version_id was changed from Version 1.7.0 to Version 1.7.4

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• assigned_to_id removed Lorenzo Masini
• pull_request_patch_supplied was configured as 0
• version was configured as master
• crashes_corrupts_data was configured as 0

[qgib]

Author Name: hamish - (hamish -)

---

Hi,

this is still present in qgis 1.7.4 and makes qgis crash out & exit(1) on the osgeo live dvd when using one of the sample (multi-user) datasets provided, where the current user does not own the grass location completely. (the location is owned by root and the user owns their mapset within it; for the iso/usb livedvd build all user owned+writable files are held in RAM, which is not practicable for a rich sample geo-dataset)

:-(

thanks,
Hamish

[qgib]

Author Name: hamish - (hamish -)

---

• crashes_corrupts_data was changed from 0 to 1
• priority_id was changed from Low to High
• os_version was changed from ubuntu 10.04 to ubuntu 11.04
• version was changed from master to 1.7.4

[qgib]

Author Name: hamish - (hamish -)

---

Hi,

some more testing and more ideas.

Micha posted some screenshots of the 1.7.4 error message in the LiveDVD ticket: https://trac.osgeo.org/osgeo/ticket/868

some of what I wrote there, reposted here:

I played around with it a bit more on the LiveDVD ISO. As far as I can tell, to get it to work the user must be the owner of the PERMANENT mapset directory, but not necessarily 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 I would expect 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 non-owned mapsets (ie nc/landsat/) just fine. perhaps a glibc call to access() is checking for permissions wrongly? (in GRASS access rules the user must actually own the GRASS 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 WINDow file on the disk. But since no file seems to be written to PERMANENT I don't think that's the case (and anyway nc_spm_08/user1/ is the open Mapset so if any, that should be the one being modified)

for now a "just make the darn thing work" end user work-around is a slight modification of Micha's 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.

regards,
Hamish

[qgib]

Author Name: hamish - (hamish -)

---

ok, so the "MAPSET PERMANENT - permission denied" comes from grass lib/gis/gisinit.c's G__gisinit() when G__mapset_permissions() is run and the current UNIX user does not match the filesystem owner:

    struct stat info;
...
    G_stat(path, &info)
...
    if (info.st_uid != getuid())
        return 0;
    if (info.st_uid != geteuid())
        return 0;

what this indicates is that qgis_master/src/providers/grass/qgsgrass.cpp is running grass/modules/qgis.g.info from QgsGrass::getInfo() with MAPSET=PERMANENT not the one you opened (here "user1").

I notice if I open the GRASS toolbox's GRASS Shell, g.gisenv shows MAPSET=user1 correctly, and "/usr/lib/qgis/grass/modules/qgis.g.info proj" shows the WKT text as expected.

when you open the GRASS mapset this should happen in QgsGrass::setMapset():

   G__setenv( "MAPSET", mapset.toUtf8().data() );

but somehow it is getting replaced by QgsGrass::setLocation()'s

  G__setenv( "MAPSET", "PERMANENT" ); // PERMANENT must always exist

since qgis.g.info.c is a read-only module, a dumb work-around is to change it to use G_no_gisinit() instead of G_gisinit(), but as this may be the cause of other bugs in the grass toolbox the reason it thinks it is in the PERMANENT mapset, when you don't have PERMAMENT open and are not trying to open a map from the PERMANENT mapset (e.g. opening @landsat from @user1) should be investigated.

also, the failure of /usr/lib/qgis/grass/modules/qgis.g.info as called by

  QByteArray data =  QgsGrass::runModule( gisdbase, location, cmd, arguments );

should be caught and safely recovered from instead of crashing the program with a "Floating point exception (core dumped)" as soon as you take another action in the GUI (maybe because the n,s,e,w region was not successfully set or the WKT proj info is uninitialized noise). QgsGrass::runModule() catches the exception and displays the error message, but 'QByteArray data' is not then checked for validity by QgsGrass::getInfo() so it continues on as if everything is ok and it has the info it came wanted.

thanks,
Hamish

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Hi, is this issue still confirmed with latest qgis/grass versions?

---

• status_id was changed from Open to Feedback

[qgib]

Author Name: Micha Silver (@micha-silver)

---

Running QGIS 1.7.4 and GRASS 6.4.2 (is that what you mean by "latest"?), I downloaded the uc_basic_spm dataset, and did "@chown -R root PERMANENT@". THen I could start GRASS, open the @user1@ LOCATION, and load the data from PERMANENT, with no problems.
I then started QGIS and the GRASS plugin. Opened the same LOCATION/MAPSET nc_basic_spm/user1, and I tried to load one of the layers from PERMANENT, as above. THe error I got is:
@cannot get projection
Cannot run module
command: /usr/local/lib/qgis/grass/modules/qgis.g.info info=proj

ERROR: MAPSET PERMANENT - permission denied
@
Just to repeat what Hamish already explained well: This error situation surfaces only in a team or educational environment, when shared data (i.e. in a PERMANENT mapset) needs to be accessible read-only. On the OSGeo Live DVD, permissions on /usr/local/share/grass are correctly set to read-only for the regular system user, specifically to emulate a classroom situation, which works fine for GRASS. But the above error renders the QGIS-GRASS plugin un-usable.

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

Just tested on master (i.e. the upcoming 1.8), problem solved. Please test on master and reopen if necessary. Thanks.

---

• fixed_version_id was changed from Version 1.7.4 to Version 1.8.0
• resolution was changed from to fixed
• status_id was changed from Feedback to Closed

[qgib]

Author Name: Micha Silver (@micha-silver)

---

I redid the test from a few months ago (then on 1.7.4), and I still get a warning window (screen shot attached) as follows:

I change the perms on a PERMANENT mapset to root:root, and start GRASS. I can view maps and copy them from the PERMANENT mapset with no problem.

Then I start qgis, and using the GRASS plugin I try to access maps in the PERMANENT mapset and I get the warning popup, then the standard qgis "Choose CRS for this layer" window opens. (On this machine I have set "Prompt for CRS" when loading a layer with unknown coordinate system.) Note that the GRASS map +does open+ after this. No crashes like before.

But something is still bothering qgis when it doesn't totally own the PERMANENT mapset.

---

• priority_id was changed from High to Normal
• version was changed from 1.7.4 to 1.8.0
• crashes_corrupts_data was changed from 1 to 0
• 4693 was configured as GRASS_plugin_error.png
• status_id was changed from Closed to Reopened

---

• GRASS_plugin_error.png (Micha Silver)

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• fixed_version_id was changed from Version 1.8.0 to Version 2.0.0

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• fixed_version_id was changed from Version 2.0.0 to Future Release - High Priority

[qgib]

Author Name: Andrea Pacifici (Andrea Pacifici)

---

This issue is still present in QGIS 2.6 for Mac OS X downloaded from the KyngChaos page. Using the GRASS plugin I try to access maps in some mapsets (no matter if PERMANENT or another user) and I get a warning popup about the unknow CRS, and the standard qgis "Choose CRS for this layer" window. At this point the file opens if it is a vector, while raster file do not opens and QGIS crashes.

The GRASS location that I attempt to open is on an external HD formatted in NTFS (in case this info could be useful to fix).

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Andrea Pacifici wrote:

This issue is still present in QGIS 2.6 for Mac OS X downloaded from the KyngChaos page. Using the GRASS plugin I try to access maps in some mapsets (no matter if PERMANENT or another user) and I get a warning popup about the unknow CRS, and the standard qgis "Choose CRS for this layer" window. At this point the file opens if it is a vector, while raster file do not opens and QGIS crashes.

The GRASS location that I attempt to open is on an external HD formatted in NTFS (in case this info could be useful to fix).

The GRASS plugin is unfortunately (mostly) unmantained. Someome (from GRASS community?) would be needed to step in.

---

• resolution was changed from fixed to

[qgib]

Author Name: Radim Blazek (@blazek)

---

This was fixed in QGIS 2.12 using GRASS_SKIP_MAPSET_OWNER_CHECK=1 environment variable for GRASS modules internally used by the plugin, e.g. to display raster etc. (not for the modules run from GRASS Tools).

---

• status_id was changed from Reopened to Closed