[GRASS-user] Fwd: GRASS on SSHFS

Markus Metz markus.metz.giswork at gmail.com
Thu Dec 13 01:06:59 PST 2012

On Tue, Dec 11, 2012 at 1:41 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
> Daniel Lee wrote:
>> [...] is there a specific reason that GRASS requires the user
>> to own a mapset, rather than just have write permission?
> Historically, there are two reasons:
> 1. To prevent multiple GRASS sessions from using the same mapset
> directory. A lock file prevented a user from having more than one
> session, and the ownership check prevented anyone other than the
> directory's owner from using a directory as the current mapset.
> 2. Because otherwise people try to share mapsets by making them
> group-writable, then discover that they can't replace maps due to
> permission issues.
> Specifically, if you allow someone else to write to your mapset
> directory, and that user has a umask of 022 (or more), any directories
> which they create (e.g. cell_misc/<mapname> directories) will be mode
> 755 (drwxr-xr-x) or less, meaning that you can't remove any files from
> that directory, and thus won't be able to delete that directory. This
> will prevent you from removing or overwriting the map using GRASS
> commands.
> Point #1 is no longer relevant, but point #2 is, at least on
> multi-user systems.

Point #1 still applies in some environments, e.g. centralized GRASS
database, users can log in with the same user name and uid from
different machines. We are using such an environment.
> On Windows, the checks are bypassed because Windows' stat() function
> doesn't report the owner and Windows doesn't have getuid().

There is a new function G_owner(), r49747, which reports the owner and
works also on Windows. We could now activate lock files and ownership
tests for Windows.

Markus M

More information about the grass-user mailing list