Hi,
when putting the PERMANENT permissions the GRASS way:
GRASS 7.0.svn (latlong):~ ls -la /grassdata/latlong | grep PERMA
drwxr-xr-x 14 neteler gis 4096 Mar 12 11:43 PERMANENT
in order to avoid that other group gis member be able to delete
PERMANENT through command line, a problem in
Markus Neteler wrote:
ERROR: MAPSET PERMANENT - permission denied
This error is generated by G__gisinit() if G__mapset_permissions()
returns 0 (mapset directory exists but not owned by the current user).
How come that it tries to write in PERMANENT? This needs to be fixed for sure.
It isn't
On Tue, Jul 16, 2013 at 10:38 PM, Hamish hamis...@yahoo.com wrote:
Markus Metz wrote:
In this case, would it be ok to enforce umask to 0022 in the start up
script?
two rules to thumb:
we shouldn't restrict others to the limits of our own imagination.
(if someone wants to set their umask
On Tue, Jul 16, 2013 at 8:44 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
...
With grass data on a network drive with multi-user access, I would
regard e.g. the contents of the PERMANENT mapset as
particularly-sensitive information.
Plenty of sites will treat
Markus Neteler wrote:
The point here is (as experienced on our local shared network
grassdata/ recently):
- GRASS allows users to enter their own mapset(s)
- GRASS allows users to read all mapsets and write into the current (own) one
- GRASS does not allow to modify the mapset of a
On Mon, Jul 15, 2013 at 5:55 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being a
Markus Metz wrote:
The convention is that programs should allow the user to control read
and write permissions via the umask, while execute permission is
determined by the program.
In this case, would it be ok to enforce umask to 0022 in the start up script?
Not literally. Those two
Markus Metz wrote:
In this case, would it be ok to enforce umask to 0022 in the start up
script?
two rules to thumb:
we shouldn't restrict others to the limits of our own imagination.
(if someone wants to set their umask to allow 777 for whatever reason
or need, why not let them?)
it's
On Sun, Jul 14, 2013 at 10:42 PM, Hamish hamis...@yahoo.com wrote:
Hi,
Markus M:
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being a folder in
the
Markus Metz wrote:
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being a folder in
the file system is created with mode 0777, thus granting write
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being a folder in
the file system is created with mode 0777, thus granting write
permissions to all. I suggest to
Hi,
Markus M:
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being a folder in
the file system is created with mode 0777, thus granting write
permissions
12 matches
Mail list logo
