access to PERMANENT (w/code)

[Malcolm Williamson]

> 
> 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
> 

Darrell McCauley querries:

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

We get away with having LOCATION directories with group, or ocassionally other,
write permission. Therefore, new mapsets can be created at any time by people
belonging to the appropriate group, directly under the single appropriate 
LOCATION. Thus, there is only one PERMANENT mapset, per a geographic region /
projection. We keep things in order around here by carefully administered doses
of fear, along with the fact that we screen all prospective students to weed out
those with previous UNIX skills or hacker convictions (just kidding!).

The symbolic link solution looks like a fair compromise of security and 
workability, although it is probably a little confusing to the UNIX novice.
As I'm writing this, I also realized that it would be pretty easy to simply have
a system and/or grass administrator be responsible for all mapset creation, and
leave the LOCATION directories as 755. If users didn't need multiple mapsets in
a given LOCATION, this would seem a fairly workable solution. Of course, this 
assumes that one has a limited number of users!
> 
> >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.
> 
Quota? Is that how much new disk capacity you're allowed to buy per year?
(Sorry, Fred/Jim!)

> 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 ;-)
> 
> 


-- 
Malcolm D. Williamson - Research Assistant       E-mail: malcolm at cast.uark.edu
Center for Advanced Spatial Technologies      Telephone: (501) 575-6159
Ozark Rm. 12                                        Fax: (501) 575-3846 
University of Arkansas              
Fayetteville, AR 72701