What are other people doing with projects/jobs that require multiple
users to access grass files? It seems that data permissions are
enforced at the owner level which stops a group from sharing project
files.
Is there a rational for this level of restriction? Is there a
work-around I'm missing?
At the moment we have created a "user" that everyone shares when they
are doing grass project work. I don't really like this solution.
Cheers,
John Harrop
John Harrop wrote:
What are other people doing with projects/jobs that require multiple
users to access grass files? It seems that data permissions are
enforced at the owner level which stops a group from sharing project
files.Is there a rational for this level of restriction?
My guess is that it's an indirect form of locking. Each user can only
have one session active at a time, each mapset directory can only be
modified by its owner, therefore you can't have multiple sessions
modifying the same mapset concurrently.
Two issues mean that this mechanism isn't particularly reliable:
1. The one-session-at-a-time rule can be circumvented just by changing
the value of HOME (the lock file is $HOME/.gislock5).
2. Nothing prevents a user from running programs in the background.
However, it does prevent users from accidentally shooting each other
in the foot.
Is there a work-around I'm missing?
Give each user their own mapset. You can read other mapsets, either by
using a fully-qualified map name (map@mapset) or by adding the other
mapsets to the search path with g.mapsets, you just can't write to
them.
You could just remove the ownership check from G__mapset_permissions()
in src/libes/gis/mapset_msc.c. However, you would then need to find
some other way to prevent one user from modifying a mapset which
another is using (e.g. change $GISBASE/etc/Init.sh to create the lock
file in the mapset directory instead of the user's home directory).
--
Glynn Clements <glynn.clements@virgin.net>
Hello Glynn, John
At Fri, 27 Jun 2003 00:10:11 +0100 Glynn Clements wrote:
However, you would then need to find
some other way to prevent one user from modifying a mapset which
another is using (e.g. change $GISBASE/etc/Init.sh to create the lock
file in the mapset directory instead of the user's home directory).
I have a modified Init.sh, which allows concurrent use with one user
(e.g. apache-user). Every session has its own mapset, where .grassrc5
and .gislock are stored in the mapset-dir.
I could provide it, if you like.
cheers
Stephan
--
Stephan Holl
GnuPG Key-ID: 11946A09
07:52:09 up 26 min, 1 user, load average: 0.00, 0.07, 0.13
On Fri, 27 Jun 2003, Glynn Clements wrote:
John Harrop wrote:
What are other people doing with projects/jobs that require
multiple users to access grass files? It seems that data
permissions are enforced at the owner level which stops a group
from sharing project files.Is there a rational for this level of restriction?
My guess is that it's an indirect form of locking. Each user can
only have one session active at a time, each mapset directory can
only be modified by its owner, therefore you can't have multiple
sessions modifying the same mapset concurrently.Two issues mean that this mechanism isn't particularly reliable:
1. The one-session-at-a-time rule can be circumvented just by
changing the value of HOME (the lock file is $HOME/.gislock5).2. Nothing prevents a user from running programs in the background.
However, it does prevent users from accidentally shooting each other
in the foot.Is there a work-around I'm missing?
I recently investigated this topic with GRASS by implementing POSIX
file locking. This was relatively easy to do because I was able to
insert most of the requisite code into the GRASS GIS library "open
file" functions, and did not have to worry about closing files because
the POSIX file locks are automatically freed when a file is closed.
Depending on the version of NFS you use, such a solution might be
usable on NFS-mounted directories (or not). I have not experimented
with my modifications enough to ensure their reliability and
robustness, however. With such a solution, proper group permissions
will allow file sharing in GRASS mapsets.
Cheers,
Martin
--
Martin Pokorny
Tucson, AZ, USA
Martin Pokorny wrote:
>> What are other people doing with projects/jobs that require
>> multiple users to access grass files? It seems that data
>> permissions are enforced at the owner level which stops a group
>> from sharing project files.
>>
>> Is there a rational for this level of restriction?
>
> My guess is that it's an indirect form of locking. Each user can
> only have one session active at a time, each mapset directory can
> only be modified by its owner, therefore you can't have multiple
> sessions modifying the same mapset concurrently.
>
> Two issues mean that this mechanism isn't particularly reliable:
>
> 1. The one-session-at-a-time rule can be circumvented just by
> changing the value of HOME (the lock file is $HOME/.gislock5).
>
> 2. Nothing prevents a user from running programs in the background.
>
> However, it does prevent users from accidentally shooting each other
> in the foot.
>
>> Is there a work-around I'm missing?I recently investigated this topic with GRASS by implementing POSIX
file locking. This was relatively easy to do because I was able to
insert most of the requisite code into the GRASS GIS library "open
file" functions, and did not have to worry about closing files because
the POSIX file locks are automatically freed when a file is closed.
Depending on the version of NFS you use, such a solution might be
usable on NFS-mounted directories (or not). I have not experimented
with my modifications enough to ensure their reliability and
robustness, however. With such a solution, proper group permissions
will allow file sharing in GRASS mapsets.
Locking individual files in G_open_cell() etc won't work as a general
solution; there just isn't enough context.
A module may read and write several files, and to be safe, everything
which it reads or writes must be locked against all other accesses
from the point that the first file is opened to the point that the
last file is closed.
Actually, even locking the entire mapset doesn't quite achieve this.
Most GRASS modules can read maps from mapsets other than the current
one. If another session happends to be modifying that mapset, the
result is undefined.
Modifications to the actual raster data aren't a problem;
G_open_cell_new() etc write to a temporary file which is renamed upon
closure. Unix filesystem semantics ensure that, if another session was
reading the file, it's contents will still be available to the reader
even after it has been "deleted" (at least on a real Unix; this isn't
true for Cygwin, but I doubt that a Cygwin installation will be
multi-user).
However, if a module reads multiple components (cellhd, data, colour
table, history, ...) from a map in another mapset, and another session
is modifying that map, the various components may not correlate.
Just because nobody has reported having been bitten by this, it
doesn't mean that it can't happen.
I don't see any prospect of fixing this in 5.0.x; IIRC, the intention
is to change the directory layout for 5.1, from MAPSET/COMPONENT/MAP
to MAPSET/MAP/COMPONENT (or is it MAPSET/TYPE/MAP/COMPONENT, where
TYPE is cell/vector etc?). That would make it much easier to lock
entire maps; e.g. ensure that every map contains a component such that
locking that component locks the entire map.
--
Glynn Clements <glynn.clements@virgin.net>
On Mon, 30 Jun 2003, Glynn Clements wrote:
Locking individual files in G_open_cell() etc won't work as a
general solution; there just isn't enough context.A module may read and write several files, and to be safe,
everything which it reads or writes must be locked against all other
accesses from the point that the first file is opened to the point
that the last file is closed.
I see---that makes perfect sense. I'm a GRASS newbie, but I want to
learn more so I can make some programming contributions. Thanks for
the useful information.
Actually, even locking the entire mapset doesn't quite achieve this.
Most GRASS modules can read maps from mapsets other than the current
one. If another session happends to be modifying that mapset, the
result is undefined.Modifications to the actual raster data aren't a problem;
G_open_cell_new() etc write to a temporary file which is renamed
upon closure. Unix filesystem semantics ensure that, if another
session was reading the file, it's contents will still be available
to the reader even after it has been "deleted" (at least on a real
Unix; this isn't true for Cygwin, but I doubt that a Cygwin
installation will be multi-user).However, if a module reads multiple components (cellhd, data, colour
table, history, ...) from a map in another mapset, and another
session is modifying that map, the various components may not
correlate.Just because nobody has reported having been bitten by this, it
doesn't mean that it can't happen.
I won't argue with that. I've learned that, generally, "can" implies
"will" in programming (and it throws off your reasoning to assume
otherwise).
Cheers,
Martin
--
Martin Pokorny
Tucson, AZ, USA
I don't see any prospect of fixing this in 5.0.x; IIRC, the intention
is to change the directory layout for 5.1, from MAPSET/COMPONENT/MAP
to MAPSET/MAP/COMPONENT (or is it MAPSET/TYPE/MAP/COMPONENT, where
TYPE is cell/vector etc?). That would make it much easier to lock
entire maps; e.g. ensure that every map contains a component such that
locking that component locks the entire map.
MAPSET/TYPE/MAP/COMPONENT would be nice for easy backup and transfer of
individual maps, instead of complicated ad hoc tar command lines for
picking filenames and directories matching the map name, etc.
TYPE would be necessary to allow you to have both vectors and raster
maps with the same name, even if that might be poor practice. Besides
raster and vector, TYPE would also have to include things like regions
(currently the not very descriptive $MAPSET/windows).
The map name becomes the master directory and the current directory
names become the files within that directory. A more radical approach
might be to automatically tar*gzip that directory and name the resulting
file map.grs or something. I guess you'd have to include PROJ_INFO in
each map dir, and the use a system of [sym]links or something to keep
them in sync might be a nightmare. Maybe only do this with a g.out.grass
export command? Or just aim to use e00 or something that is already
standard, documented, & open? We can copy DXF and shape files around
easily today, but not grass maps separate from their mapset and that's a
pain.
Even if this is a long way off and gone over before, I think it is good
to establish & reiterate what people would like to have eventually.
best,
Hamish