[GRASS-dev] How to get data from a location where the user does not own any mapset?

Radim Blazek radim.blazek at gmail.com
Wed Sep 23 00:28:13 PDT 2015


Thanks for the extensive explanation, Glynn.

On Tue, Sep 22, 2015 at 5:18 PM, Glynn Clements
<glynn at gclements.plus.com> 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


More information about the grass-dev mailing list