[GRASS-dev] [Fwd: Re: GRASS permission issue]

[Glynn Clements]

Tim Michelsen wrote:

> As it seems to occuring over and over, I think this is a relict from the
> early days of computing.
> To my opinion there is no need to think that the GRASS users are by
> default concurrently working on the same location.

The issue isn't related to concurrent use. If a mapset is modified by
someone other than its owner, the owner may be unable to delete or
replace maps.

Ultimately, this is a band-aid for user error (creating group-writable
directories without fully understanding the implications), but it does
appear to be necessary (a number of people who have disabled the
ownership check have subsequently reported being bitten by the above
issue).

> This may have been true in old days where many people where sharing
> mainframes or today in server environments.
> Nowdays, desktops and notebooks are cheap. We are mostly using GRASS
> like GIMP or Office programs: one person at one single computer.

GRASS is used quite extensively in institutional environments where
multi-user systems and/or filesystems aren't all that uncommon.

> Thus the following defaults may be revised:
> * requiering the user to be the _owner_ or the files on linux/unix systems:
> 	* many users use shared partitions between windows and linux and
> automount these
> 	* also on linux systems the one-user-one-computer is getting common

In which case, the solution is obvious: when mounting Windows
partitions, set the owner to the computer's "sole user", rather than
to root.

> 	* working with having GRASSDATADIR on an external large drive is difficult

Why?

> * let users write on more than one mapset

A single user can have sessions open in any number of mapsets, and you
can switch between mapsets within a session.

> 	* again, concurrent use of a location is rather rare

For you, maybe; some users regularly have multiple sessions active. 
Preventing multiple sessions from using the same mapset is handled by
the .gislock file, and is a necessary restriction, particularly due to
the way that the VAR and WIND files are used.

> 	* this would help to get a file sorting function in order to clean up
> the GRASSDIR once in a while
> 		(add a command g.move, http://trac.osgeo.org/grass/ticket/891)
> 	* sharing information with between mapsets/locations instead of
> replication saves disk space
>            (http://thread.gmane.org/gmane.comp.gis.grass.user/30333)
> this is currently not possible

Sharing data between locations isn't possible. A desire to do so
indicates a user error, i.e. using multiple locations when a single
location should have been used.

> I know that some of the old cats or power users with _very special_
> needs like server processing setups will be against a change which
> affects the permissions/rights situation and capabilities of GRASS.
> But please consider that such capabilities could still be maintained on
> a non-default basis as compile options.
> And the general public certainly wants an easy to use system where such
> pecularities like permissions are important.
> 
> Be reminded that GRASS on Windows (focus of current release cycle) does
> not know such rights at all.

That's partly because no-understands Windows permissions well enough
to implement it, but mostly because Windows systems tend not to be
multi-user.

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