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'
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 g.exte
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 diff
On Tue, Jul 16, 2013 at 8:44 PM, Glynn Clements
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 PERMANENT as public dat
On Tue, Jul 16, 2013 at 10:38 PM, Hamish 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 to allo
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
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
On Mon, Jul 15, 2013 at 5:55 PM, Glynn Clements
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 folder in
>> th
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
> p
On Sun, Jul 14, 2013 at 10:42 PM, Hamish 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 file syst
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
> permiss
>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
12 matches
Mail list logo
