[GRASS-user] how to enable write access for the UNIX group?

[Glynn Clements]

Maciej Sieczka wrote:

> >> How do enable members of a UNIX group to have write access to shared
> >> GRASS locations/mapsets from GRASS?
> >>
> >> To check if that's possible with umask, I do:
> >>
> >> $ umask 6
> >> $ grass63
> >> (setup new location, create mapsets)
> >>
> >> The location and mapsets directories are created with 771 rights. The
> >> dbf subdir too. WIND, DEFAULT_WIND, MYNAME, .gislock and .bashrc files
> >> are created with 660. Good. But, any newly created mapset elements
> >> (subdirs for vectors, raster etc.) still have only read access for the
> >> group. Do GRASS commands ignore umask setting?
> 
> >They shouldn't. Any libgis functions which create directories use
> >G_mkdir(), which uses 0777. The only references to chmod() are for the
> >session directory (/tmp/grass6-<user>-<pid> on Unix) and G_rc_path().
> >There are no calls to umask() in libgis.
> >
> >Similarly, the raster files are created as 0666, while the vector
> >library uses G_fopen_new(), which uses G__open(), which uses 0666.
> >
> >FWIW, I can't reproduce the problem:
> >
> >$ rm -rf /opt/grass-data/spearfish57/glynn/windows
> >$ umask 0000
> >$ g.region save=foo
> >$ ls -ld /opt/grass-data/spearfish57/glynn/windows
> >drwxrwxrwx 2 glynn users 4096 Sep 24 00:58
> /opt/grass-data/spearfish57/glynn/windows/
> >$ ls -l /opt/grass-data/spearfish57/glynn/windows
> >total 4
> >-rw-rw-rw- 1 glynn users 287 Sep 24 00:58 foo
> >$ umask 0022
> >$ rm -rf /opt/grass-data/spearfish57/glynn/windows
> >$ g.region save=foo
> >$ ls -ld /opt/grass-data/spearfish57/glynn/windows
> >drwxr-xr-x 2 glynn users 4096 Sep 24 00:58
> /opt/grass-data/spearfish57/glynn/windows/
> >$ ls -l /opt/grass-data/spearfish57/glynn/windows
> >total 4
> >-rw-r--r-- 1 glynn users 287 Sep 24 00:58 foo
> 
> Please note that I run umask *before* entering GRASS, while you do it
> *after*. Shouldn't GRASS session preserve umask set before entering it? It
> doesn't. It forces 0022 instead:
> 
> $ umask 2
> $ umask
> 0002
> $ grass63
> $ umask
> 0022
> $ exit
> $ umask
> 0002

I checked grass63 and Init.sh for references to umask, but didn't find
any (other than a temporary setting of 077 while creating the session
directory). I have now found the likely cause:

The temporary .bashrc file which Init.sh creates sources /etc/profile,
which may set the umask.

It probably *shouldn't* be sourcing /etc/profile, as that script is
only supposed to be used for login shells.

However, changing it will probably break stuff for some users, who may
be relying upon /etc/profile being sourced without realising it.

Note that sourcing /etc/profile is the first thing which the created
.bashrc file does, so any settings in ~/.grass.bashrc will override
those done in /etc/profile.

Also, you can inhibit reading /etc/profile by setting the environment
variable PROFILEREAD to any non-empty string before starting GRASS,
e.g.:

	export PROFILEREAD=1
	grass63

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