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

[Markus Neteler]

On Tue, Mar 30, 2010 at 4:18 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
> 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.

By default not but all those working in a group (like us here) are VERY
happy about this possibility.
In all institutions in which I worked since 2001 we used this approach
for the benefit of easy data management and saving disk space.

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

Still true today (maybe even more since data continue to grow).

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

... I agree.

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

It works pretty well: we have a large disk array here which is mounted locally
on each user's computer at boot time (laptops btw) and you are ready to go.
Also the software (GDAL, PROJ, GRASS, QGIS, R etc) is offered like this:
shared NFS directory which is mounted on each computer automatically.
Adding the path of the lib/ directory to LD_LIBRARY_PATH and the binary
path to PATH (on Linux or Unix-like) is sufficient to provide all users here
with a single installation. *That's* easy to maintain because I have only one
installation to manage, not many.


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

[g.mapset (without s) is doing that]

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

Concurrent use is the most common thing here. In the PERMANENT
location, we store the base cartography; then we have numerous mapsets,
partially project based, partially user based. This is quite self-organizing
and scales well even with many users.
All users can be sure that the base cartography is well maintained and
that there are not concurrent copies of it.

>>       * 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)

g.move could be interesting (note that there is alreadt r.pack/r.unpack in
the GRASS Addons) but immediately some users will start to move maps
into locations with a different projection etc... quite some "security" checks
would be needed.

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

If they have to be shared, just put them in sharable mapsets because
there is no need to put them into different locations. If the latter is
the case, then you will likely have different projections and you would
have to reproject the maps in any case...

>> I know that some of the old cats or power users with _very special_

I am not *that* old ;-)

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

Luckily it is open source and you could just remove these checks locally
and recompile. Or make directories world-writable.

>> And the general public certainly wants an easy to use system where such
>> pecularities like permissions are important.

I would be particulary unhappy if my colleagues started to overwrite my
data (accidentially or on purpose). The file permissions protect me from that.
I don't see the problem you have.

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

Best,
Markus