mapset permissions?

GRASS GRASS user
1

?ecn?purdue?edu}@bnr.ca>
NNTP-Posting-Host: ux1.cso.uiuc.edu
Originator: daemon@ux1.cso.uiuc.edu

mccauley@ecn.purdue.edu (James Darrell McCauley) writes:

Bingo! "umask(0);" on line 70. I remove this line and my shell's
umask was obeyed.

Here is what Michael says to this:

GRASS creates all files with 0666 and all directories in a mapset with
0777. It wants to make sure that all files in a mapset are public
readable and all directories are piblic read/searchable. (Perhaps a
umask of 022 might be ok - removing write for group/other. But look at
G_tempfile() - the Panel_Save in the graphics needs a publicly
writeable tempfile.)

Access to the maspset and to all its files and directories
is controlled by g.access which changes permission on the mapset
itlsef so that group/other can/can't see into the mapset (by removing
tjhe r and x permissions).

If we make changes to this we risk breaking what works.
We have to make sure that anybody can read all files in any mapset
as long as the permission on the mapset itself allow users to
see the files (these permisison are under user control with g.access).

Michael (ext 277)

I just wanted to post this warning for Michael for those
who want to get rid of umask(0)
lga

2

Olga Waupotitsch (olga@zorro.cecer.army.mil) writes on 9 March 1995:

mccauley@ecn.purdue.edu (James Darrell McCauley) writes:

Bingo! "umask(0);" on line 70. I remove this line and my shell's
umask was obeyed.

Here is what Michael says to this:

GRASS creates all files with 0666 and all directories in a mapset with
0777. It wants to make sure that all files in a mapset are public
readable and all directories are piblic read/searchable. (Perhaps a

why? I can think of no technical reasons for why this *has* to be
this way. If I have a umask set a certain way, I expect all software
to obey it (under normal circumstances, unless we're talking about
the infamous locks directory or cases where sticky bits are involved)

umask of 022 might be ok - removing write for group/other. But look at
G_tempfile() - the Panel_Save in the graphics needs a publicly
writeable tempfile.)

I don't know what this is about. I grep'ed for Panel_Save in
all of src/{display,libes,raster} and couldn't find it.

Access to the maspset and to all its files and directories
is controlled by g.access which changes permission on the mapset
itlsef so that group/other can/can't see into the mapset (by removing
tjhe r and x permissions).

sure - I can use 'chmod' after-the-fact, but I shouldn't have to.

If we make changes to this we risk breaking what works.

I'd be willing to make all changes so that it does work.
Can anyone tell me where this Panel_Save thing is? Any other
things that might break?

We have to make sure that anybody can read all files in any mapset
as long as the permission on the mapset itself allow users to
see the files (these permisison are under user control with g.access).

Michael (ext 277)

I just wanted to post this warning for Michael for those
who want to get rid of umask(0)
lga

--
James Darrell McCauley, PhD http://soils.ecn.purdue.edu/~mccauley/
Dept of Agricultural Engineering mccauley@ecn.purdue.edu
Purdue University new-> tel: 317.494.1198 fax: 317.496.1115