access to PERMANENT (w/code)

[Darrell McCauley]

Malcolm Williamson (malcolm at cast.uark.edu) writes on 19 Aug 93:
>I'm missing something here. Why do you want multiple locations with access to
>spearfish data? Do you not have centrally accessible data? We use traditional
>GRASS directory structures, with a single location for a given projection /
>geographic region. PERMANENT is writable by owner, readable by all. Each user
>creates a new mapset owned by him/herself, with potential read access to all

*where* and *how* does each user create a new mapset?

>I suspect that you have some special needs that you haven't mentioned, because
>the traditional structure seems to meet most of ours. comments?

The point is that spearfish/PERMANENT, spearfish/malcom, spearfish/mccauley,
and spearfish/greg need to "appear" in the *same* directory. 

In most academic environments, it is not wise to have directories
world writable, so creating individual mapsets under /usr/grass/data
(or wherever) is not possible/advisable.

So, there are (at least) two work-arounds here. You can create a link
in /usr/grass/data/spearfish TO USERS' MAPSETS (which requires
permission of the person owning this directory + it's a lot
of hassle, depending on how many grass users you have), or,
as Greg outlined (I believe), you can create links
TO PERMANENT MAPSETS. We also do the latter here at Purdue.

[I didn't read Greg's posting in detail before he deleted it,
 but I believe that I got the crux of it]

In short, new grass users are instructed to do the following
here at Purdue:
  mkdir data
  cd data
  mkdir spearfish
  cd spearfish
  ln -s /usr/grass/data/spearfish/PERMENENT

Then, when they run grass, ~/data (expanded) is specified
as the DATABASE. Any files written by them have their
umask (or at least they should - I found a .grassrc file
that was world writable the other day) and they are
forced to respect quotas.

This security- and quota-minded approach works well for
academic environments.

Aside: Security may be a non-issue because of the bad locking system.
I hate to harp on this but it is a problem in academic computing 
environments like Purdue (where anyone of 10000 users can write
whatever they want to the locks directory). Maybe someday I'll get
time to work on the grass server daemon that I've planned (for 
display and digitizing devices and for restricting users to one grass 
session, even on across networks where grass binaries are 'mount'ed) .

Other than that, if you have a machine where you trust *every*
user on *every* system that mounts the grass data, world 
writable directories may not be too bad (did I say that? :o )

--Darrell

P.S. If you're from Purdue: don't even think about it - there are ways to 
keep track of things like this, like named-pipe/daemon "trap doors" 
(in case you "look" at the wrong files) that send mail to me and/or root 
when something out of the ordinary happens, and like crontabs that check 
every fifteen minutes for anything fishy looking, and like trojan
scripts in case you have a bad path and type 'ls' or 
'more' in the wrong place, and like ... you get the picture ;-)