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

[Glynn Clements]

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..

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 could 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.

-- 
Glynn Clements <glynn at gclements.plus.com>