On Tue, Dec 11, 2012 at 1:41 PM, Glynn Clements <gl...@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 _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
