Grass5.0beta2 install prob with binaries

Just today I had a similar problem. The root umask is usually set to
something restrictive. You will need to get the appropriate directories
to be rwx to everyone. Since this might be a system security nightmare,
you might want to add yourself to group 'wheel' or whatever root was
using when creating the grass directories.

If I understand what is going on, the real problem is that grass wants
write permission to directories under /usr/local/grass5. Ideally the
lock files would instead be in the user home directory, maybe in some
place like ~/.grass, as with Netscape and other utilities. This
might (again, if I understand enough grass) make the installation more
secure. And there seem to be a number of lock and other little files
floating about.

Thanks BTW for working on a new X24 driver. The current version is a bit
flakey on my linux 2.0.36 X11R6 box.

Hi,

I think you are not able to run grass as a regular user. I guess you
do not have access to the /usr/local/ directory on your machines.

On Fri, 20 Aug 1999, R. Joe Brandon wrote:

> After loading the grass5.02binaries on my MkLinux system (Based on
> RedHat5.x) I received the following error when I tried to exceute the
> program (as a user, not as root)
>
> /usr/local/grass5/etc/GIS.sh: /usr/local/grass5/etc/lock: cannot execute
> binary file Unable to properly access /home/grass/.gislock
> Please notify system personel.
>
> I have checked permissions on the offending files but all checks out ok.
>
> Any ideas?
>
> R. Joe
>
> mailto:rjoe_brandon@iname.com
> http://www.cast.uark.edu/~rjoe

Adios,
Chris
--
C.S. Cornuelle
School of Mathematics/MCIM
206 Church St. SE
University of Minnesota
Minneapolis, MN 55455
(612) 626-8930, 624-9069
bob@math.umn.edu
--
Ferventer Vestite

On Fri, Aug 20, 1999 at 03:47:38PM -0500, bob@math.umn.edu wrote:

Ideally the
lock files would instead be in the user home directory, maybe in some
place like ~/.grass, as with Netscape and other utilities. This
might (again, if I understand enough grass) make the installation more
secure. And there seem to be a number of lock and other little files
floating about.

Some lockfiles have to be global, just think of the number of
graphic display pipes used or physical inputs devices.
So two ways from there to improve the situation:

  Make the locking executables setgid or setuid.
  (and have just one executable doing the locking.)
  And/or use the /tmp directory.

  Localise all global lockable resources.
  (Unlikely to work.)

Bernhard