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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
