Thanks for the extensive explanation, Glynn. On Tue, Sep 22, 2015 at 5:18 PM, Glynn Clements <[email protected]> wrote: > > Radim Blazek wrote: > >> Is it possible to access data through GRASS modules in a location >> where the user does not own any mapset? Each GRASS module calls first >> G_gisinit() which checks if current mapset returned by G_mapset() is >> owned by current user. If it is not, it ends with fatal error. How to >> get around this for locations where the user does not own any mapset? > > In general, you can only access data in the current location. For most > modules, it's meaningless to access data from a different location as > the projection will be wrong. A handful of modules (e.g. r.proj, > v.proj) support accessing data from a different location, and in such > cases there's no need for the user to own the source mapset, or even > to own any mapset in the source location. > > Since r54264, it is possible to bypass the ownership check by setting > GRASS_SKIP_MAPSET_OWNER_CHECK to any non-empty string. This was added > mostly for accessing VFAT/NTFS-format external drives or network > shares where the ownership checks don't behave correctly. It should > not be used on multi-user systems, nor set by programs..
Perfect, that is what I need. Why GRASS_SKIP_MAPSET_OWNER_CHECK should not be set by programs for read only access? > But other than that, you cannot make a mapset the current mapset (i.e. > the one you can modify) unless you own it. You can access data from > any mapset for which you have the relevant filesystem permissions > (i.e. read permission for files, execute permission for the ancestor > directories, read permission for any directories which need to be > enumerated). > > Originally this restriction was related to locking (the lock file was > created in the user's home directory, so being able to set the current > mapset to a directory which you didn't own meant that you > coGRASS_SKIP_MAPSET_OWNER_CHECKuld have > multiple sessions modifying a mapset concurrently). > > That's no longer an issue (the lock file is created in the mapset > directory). Howver, the other issue is that allowing someone other > than the owner to modify the directory can result in problems for its > owner. > > Creating a new map typically creates a subdirectory of cell_misc for > that map, and some files within it (e.g. a "null" file). Any new files > and subdirectories will be owned by their creator (not the mapset's > owner) and will have permissions determined by the current umask. The > result is that there's no guarantee that tha mapset's owner will be > able to delete (or even access) such files or directories. > > In short, it's a safety mechanism against people trying to share > directories by making them group-writeable without fully understanding > the implications. I am only interested in read only access. The purpose is to be able to read and display data in QGIS. I believe that read only access to a location where the user does not own any mapset is a legal requirement, isn't it? Radim _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
