I modified the unix socket routines to always use /tmp/grass-$USER/
as the directory. This should overcome some problems with NFS
mounts. Hopefully this works okay for everyone.
--
Eric G. Miller <egm2@jps.net>
On Mon, Oct 08, 2001 at 04:24:08PM -0700, Eric G. Miller wrote:
I modified the unix socket routines to always use /tmp/grass-$USER/
as the directory. This should overcome some problems with NFS
mounts. Hopefully this works okay for everyone.
Thanks, Eric!
It's working properly here.
For the others: To test, run
cvs up src/libes/gis
gmake5 src/libes/gis
gmake5 -i src/display/devices/XDRIVER
gmake5 -i src/display/d.mon
d.mon x0
Check if /tmp/grass-$USER/ is present, containing the sockets file.
Best regards
Markus
On Tue, Oct 09, 2001 at 09:23:47AM +0200, Markus Neteler wrote:
On Mon, Oct 08, 2001 at 04:24:08PM -0700, Eric G. Miller wrote:
> I modified the unix socket routines to always use /tmp/grass-$USER/
> as the directory. This should overcome some problems with NFS
> mounts. Hopefully this works okay for everyone.Thanks, Eric!
It's working properly here.
For the others: To test, run
cvs up src/libes/gis
gmake5 src/libes/gis
gmake5 -i src/display/devices/XDRIVER
gmake5 -i src/display/d.mon
d.mon x0Check if /tmp/grass-$USER/ is present, containing the sockets file.
Sorry, not to forget: You have to recompile all d.* modules
and other monitor related modules!
Markus
On Mon, Oct 08, 2001 at 04:24:08PM -0700, Eric G. Miller wrote:
I modified the unix socket routines to always use /tmp/grass-$USER/
as the directory. This should overcome some problems with NFS
mounts. Hopefully this works okay for everyone.
Not having thought about this deeply:
Is there a chance of a race tmp condition which makes it
possible to gain files with the user's permission?
Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Tue, Oct 09, 2001 at 11:25:08AM +0200, Bernhard Reiter wrote:
On Mon, Oct 08, 2001 at 04:24:08PM -0700, Eric G. Miller wrote:
> I modified the unix socket routines to always use /tmp/grass-$USER/
> as the directory. This should overcome some problems with NFS
> mounts. Hopefully this works okay for everyone.
Hi Eric,
unfortunately there is a related bug:
GRASS:~ > d.rast dtm10
100%
GRASS:~ > d.what.rast
Failed to get socket name for monitor <x0>.
ERROR: No graphics device selected
GRASS:~ > d.vect viapri
.. working
GRASS:~ > d.what.vect
No socket to connect to for monitor <x0>.
ERROR: No graphics device selected
GRASS:~ > d.sites points
.. working
GRASS:~ > d.what.sites
Failed to get socket name for monitor <x0>.
ERROR: No graphics device selected
GRASS:~ > d.zoom
Failed to get socket name for monitor <x0>.
ERROR: No graphics device selected
However, v.digit seems to work.
I guess that R_open_driver() is causing problems.
src/libes/raster/io.c
Please have another look into this,
thanks
Markus
Bernhard Reiter wrote:
> I modified the unix socket routines to always use /tmp/grass-$USER/
> as the directory. This should overcome some problems with NFS
> mounts. Hopefully this works okay for everyone.Not having thought about this deeply:
Is there a chance of a race tmp condition which makes it
possible to gain files with the user's permission?
I'm fairly sure that it's safe.
The code first does an lstat() on /tmp/grass-<username> [1]
If it fails, the directory is created with mkdir(), which will fail
with EEXIST if the pathname already exists.
If it succeeds, the code ensures that the target is a directory
(according to the lstat() call), then sets the permissions with
chmod(), which will fail if the user doesn't own the directory (and
isn't root).
It's much easier to create directories safely than to create files.
[1] and not /tmp/grass-$USER; the username comes from G_whoami(),
which uses getpwuid(getuid())->pw_name, not getenv("USER").
BTW, G_whoami() should just fail if getpwuid(getuid()) returns NULL,
by returning NULL, calling G_fatal_error(), segfaulting or whatever.
It certainly shouldn't return a valid pointer.
--
Glynn Clements <glynn.clements@virgin.net>
On Tue, 9 Oct 2001 11:50:43 +0200, Markus Neteler <neteler@itc.it> wrote:
On Tue, Oct 09, 2001 at 11:25:08AM +0200, Bernhard Reiter wrote:
> On Mon, Oct 08, 2001 at 04:24:08PM -0700, Eric G. Miller wrote:
> > I modified the unix socket routines to always use /tmp/grass-$USER/
> > as the directory. This should overcome some problems with NFS
> > mounts. Hopefully this works okay for everyone.Hi Eric,
unfortunately there is a related bug:
GRASS:~ > d.rast dtm10
100%
GRASS:~ > d.what.rast
Failed to get socket name for monitor <x0>.
ERROR: No graphics device selected
I suspect some sort of incomplete recompilation at work here. All the
d.* modules should eventually be getting the socket file descriptor
from the same place, so it doesn't make sense why some would work and
others wouldn't. But I'm seeing the same. I'm doing a clean compilation
at the moment, but must go to work now...
--
Eric G. Miller <egm2@jps.net>
On Tue, 9 Oct 2001 11:25:08 +0200, Bernhard Reiter <bernhard@intevation.de> wrote:
On Mon, Oct 08, 2001 at 04:24:08PM -0700, Eric G. Miller wrote:
> I modified the unix socket routines to always use /tmp/grass-$USER/
> as the directory. This should overcome some problems with NFS
> mounts. Hopefully this works okay for everyone.Not having thought about this deeply:
Is there a chance of a race tmp condition which makes it
possible to gain files with the user's permission?
As Glynn has outlined, I tried to do some modicum of security checking.
Worries about using /tmp is why I didn't do so previously. If anyone
can find security problems in the code, I'd like to know what they
are and how to fix them.
--
Eric G. Miller <egm2@jps.net>
Think I fixed the bug. G_whoami() returns a static pointer
to char, which it wants to use in subsequent calls. Seems, gcc
was letting me free it and letting G_whoami() use it again later,
but it now contained something entirely different (the value of
the path to the socket file!). Sheesh, a segfault would've made
that easier to find...
Anyway, that me know if there are any more troubles...
--
Eric G. Miller <egm2@jps.net>