Re: Could not open CORBA factory

["David T. Bath" <bathd edipost auspost com au>]

Leif Wickland wrote:
> 
> Doug,
> Did you ever resolve these problems?  I'm suffering similar problems with my
> gnome-db/libgda/mysql setup.
> 
> > -----Original Message-----
> > From: gnome-db-list-admin gnome org
> > [mailto:gnome-db-list-admin gnome org]On Behalf Of Doug Olson
> > Sent: Monday, July 17, 2000 11:18 AM
> > To: gnome-db-list gnome org
> > Subject: Could not open CORBA factory

> > I have installed Gnome-DB 0.0.96
> >
Had similar problems with the Oracle gda server if you can
do it as root, but then cannot open a session as another
user.
A file created under /tmp was not writeable by anyone but the
owner of the gda server (haven't got the code with me) for that
database, and was typically created owned by root.

Runtime fix (yuk)
	Grovel around the /tmp dir, find the gda file
	and chmod ugo+rw
Code fix (also yuk)
	Create the file with different protection in the
	driver code.
Other issues:
	If all users share the same file for connecting with
	the driver, and need to read and write, then any user
	can see what statements others are sending.
	This is a big security hole.
	Should we write to $TMPDIR ?
	Should we prefer writing to $HOME/tmp ?
	Should we allow a nominated file rather than a
	hard-coded one?
	Even if we open in append mode, on half the OSes
	all usrs will still be able to read.
	This is not an easy issue to resolve, affected all
	the 0.9[56] drivers I could see, and smacks of
	pc-centrism : i.e. one user per workstation, which
	is what we are trying to avoid.  This SEVERELY limits
	the use of gnome-db on boxes like solaris/aix/hp/
	tru64 (and dare I say z-series) and even on linux
	servers in a corporate environment (if I'm right
	in my diagnoses of course).
	
	A possible fix (if I'm not talking through my backside)
	is to kick of a process owned by root writing to a
	root-only file, sucking from a named pipe, and it is
	this named pipe that people append to.  Even that has
	problems when people disconnect and send an EOF to the
	pipe.  --OR-- we write to another socket with a background
	process sucking on that - again writing the logs to a
	root and/or dba-only readable file.
	And if we do that, we might have to think about a
	compile or runtime option for who owns the file: the
	informix DBA might be a different person from the Oracle
	DBA.  Or should it be groups?  Should such runtime options
	come from an options file under ${sysconfig} ??????
-- 
David T. Bath bathd edipost auspost com au
+613 9204 8713 (W) 0418 316 634 (Mbl)
Quantum computing precludes omniscience and vice versa.