Please correct me: Informix security sucks
Greg Starnes
Ok, I am a converted oracle dork, so most of my posts start with: I know
Oracle does this. This is bad because i really like Informix (I truely am a
glutton for punishment).
Oracle has security at the OS and Database level. All I can find from
Informix is that they only have security at the OS level. SO, if you have
root privileges for the OS, you can get into the tables of our product
(which, obviously we dont want to happen).
I work in a software development environment. We are creating an accounting
product with a java front end, and an Informix back-end, which will be
installed to a clients server via our Post sales support team. We've worked
long and hard to get the DB model to where it is. If someone can get into
the database from some 3rd party tool (DB access, etc.), they can take our
tables and start an accounting company. I dont want this to happen; i'd
much rather they pay me for my product. is there a way to keep them from
doing this?
David Stes
>
> Oracle has security at the OS and Database level. All I can find from
> Informix is that they only have security at the OS level. SO, if you have
> root privileges for the OS, you can get into the tables of our product
> (which, obviously we dont want to happen).
Having security at both os and database level seems complex.
I like the Informix simplicity of having only OS level security.
There's also a risk of duplication, where the database would implement
services that can/are better provided by the OS.
Maybe there exists for example a "crypto-filesystem" where the
read/write's to files would be encrypted so you could have a layer of
security (provided by the OS) like that.
But I also sometimes worry about Informix security.
Wouldn't informix SE security for Linux (I use SE, I don't know about
Dynamic) be improved, by implementing communication IPC through simple
pipes ?
I don't need the remote capabilities of "sesoctcp" and I think both
security and performance could be better if communication through pipes
(seipcpip?) were supported.
This is something that I worry about, that the informix daemon is
listening on a socket and would accept connections; I'd rather have it
listen only on a domain socket or pipe, but I don't think there's a way
to do it right now.
Greg Starnes
package we are selling. Most of the value of this product is in the schema
of the tables. If we set up this package on our clients computer (who will
have root privelidges on the OS), they can go in and steal the layout of the
tables.
With Oracle, there is security at the DB level, so we can preset the
privelidges on the tables, so that they cant get into them and rip them off
(ie. take the schema and use it to set up thier own accounting dept (we are
building an accounting package)).
Am I going to have to tell my boss that Oracle is in fact superior... This
could be a deal breaker for Informix, and I'd love to NOT see that happen.
Thanks for your comments, it raises some interesting questions for our web
server.
"David Stes" <st...@pandora.be> wrote in message
news:3908A205...@pandora.be...
irwin_g...@my-deja.com
and/or hardocoded user-ID and password within your application, or will
database connections be made on a user by user basis? If the former,
you can set things up so only the specific application user-ID can
connect to the database. I don't think you can stop user "informix"
(considered *the* DBA/SA) from connecting. In any case, you would need
root user permissions on your customers systems to create the special
application user ID without them knowing the password. If you plan on
individual user-IDs and passwords for each user for the database
connections, then I'm afraid you're out of luck.
I really question the practice of hiding the database from the customer
however. A big part of the value of applications based on a relational
DB is the ability to use a variety of third party tools for report
generation, ad-hoc queries, etc. If you lock things up so tight that
users cannot connect using ODBC or other methods outside of your
application, then you stop them from using any of these packages.
Personally, I would not recommend a package that locked the data up in
some sort of proprietary or inaccessible (outside of the application)
format to any of my clients.
IMHO I don't think you should be too conerned about letting
clients/users know the data structures you are using. A tremendous
portion of the value of any software package is in the code itself.
Just knowing the data structures is not enough to make reverse
engineering easy, unless the business logic you are implementing is
trivial. In that case the value of the entire application would be
questionable.
In article <8ea9k0$kv5$1...@paxfeed.eni.net>,
--
Irwin Goldstein
Objective Software Systems, Inc.
http://www.objectsoft.com
Sent via Deja.com http://www.deja.com/
Before you buy.
Steven Hauser
and design. And yes there is security, just make another user with
low permissions.
--
---------------------------------------------------------
Steven Hauser
email: haus...@tc.umn.edu URL: http://www.tc.umn.edu/~hause011
---------------------------------------------------------
Daniel Wood
from directly reading the catalog information from the disk bypassing the
database engine. Unless encrypted this would be trivial. I believe Oracle
does document the layout of their disk structures.
It would be easy to write a utility to dump the system catalog information.
I don't want to argue which product is superior but I will say that having
a feature that provides a false sense of security does not make any product
superior.
Obnoxio The Clown
From: "Greg Starnes" <gsta...@ep-services.com>
>
>My problem is that were using Informix for the back-end of a software
>package we are selling. Most of the value of this product is in the schema
>of the tables. If we set up this package on our clients computer (who will
>have root privelidges on the OS), they can go in and steal the layout of
>the
>tables.
Your entire application's value is in the schema? Nothing on the front end?
Most applications (SAP, BAAN, JDE, PeopleSoft) *publish* their schemas to
make them more open to third party applications. So you seem to be blowing
against the wind here.
>With Oracle, there is security at the DB level, so we can preset the
>privelidges on the tables, so that they cant get into them and rip them off
>(ie. take the schema and use it to set up thier own accounting dept (we are
>building an accounting package)).
Gee, if I'd known it was that easy to write an accounting application, I
would have written one ages ago.
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Richard Spitz
> All I can find from
> Informix is that they only have security at the OS level. SO, if you have
> root privileges for the OS, you can get into the tables of our product
> (which, obviously we dont want to happen).
That is not quite true. There are no special permissions for root for
access to Informix databases. Of course, root can access any data on
the OS level, but that won't do him much good because all he will see
is a bunch of binary garbage that is rather difficult to decode. It
CAN be done, but that would require intimate knowledge of the internal
workings of Informix.
> If someone can get into
> the database from some 3rd party tool (DB access, etc.), they can take our
> tables and start an accounting company. I dont want this to happen; i'd
> much rather they pay me for my product. is there a way to keep them from
> doing this?
To get "into the database", a user needs at least a CONNECT privilege.
To access data in a table, he needs additional privileges on the table
level. The only user who has access to everything without special
privileges is "informix". AFAIK, having a user "informix" and a group
"informix" is a prerequisite for running the Informix backend, so
root could always do a "su - informix" to access the data.
So there is no way to handle the database as a "black box" the way you
would like to have it. On the other hand, I would be very hesitant
to buy an accounting package that stores its data in such a black
box. And are you sure that Oracle would permit you to do this?
Regards, Richard
--
+--------------------------+------------------------------------------+
| Dr. med Richard Spitz | INTERNET: sp...@ana.med.uni-muenchen.de |
| EDV-Gruppe Anaesthesie | Tel : +49-89-7095-6110 |
| Klinikum Grosshadern | FAX : +49-89-7095-6420 |
| 81366 Munich, Germany | GSM : +49-172-8933578 |
+--------------------------+------------------------------------------+
Ron M. Flannery
On Fri, 28 Apr 2000, Daniel Wood wrote:
> So exactly how does database permissions prevent a user with root access
> from directly reading the catalog information from the disk bypassing the
> database engine. Unless encrypted this would be trivial. I believe Oracle
> does document the layout of their disk structures.
All database information is stored in binary format and isn't easily (or
feasibly) readable. Also, root doesn't have any special
privileges; he/she is just like any user and needs to be granted access.
But, as with Oracle, root can *become* any user - there's no database
that can get around that.
>
> It would be easy to write a utility to dump the system catalog information.
Nope. See above.
>
> I don't want to argue which product is superior but I will say that having
> a feature that provides a false sense of security does not make any product
> superior.
Any user that can access the data needs a valid login ID. If the database
administrator takes proper care, you should be safe.
- Ron F.
________________________________________________________________________
Ron Flannery <mailto:rfla...@informixhandbook.com>, 248-887-8470x40
Lead author, Informix Handbook President, One Point Solutions
"Your Complete Reference" "Informix & Web/Database solutions"
http://www.informixhandbook.com http://www.one-point.com
________________________________________________________________________
>
> Greg Starnes wrote:
>
> > My problem is that were using Informix for the back-end of a software
> > package we are selling. Most of the value of this product is in the schema
> > of the tables. If we set up this package on our clients computer (who will
> > have root privelidges on the OS), they can go in and steal the layout of the
> > tables.
> >
> > With Oracle, there is security at the DB level, so we can preset the
> > privelidges on the tables, so that they cant get into them and rip them off
> > (ie. take the schema and use it to set up thier own accounting dept (we are
> > building an accounting package)).
> >
> > Am I going to have to tell my boss that Oracle is in fact superior... This
> > could be a deal breaker for Informix, and I'd love to NOT see that happen.
> >
> > Thanks for your comments, it raises some interesting questions for our web
> > server.
> >
> > "David Stes" <st...@pandora.be> wrote in message
> > news:3908A205...@pandora.be...
> > > Greg Starnes wrote:
> > > >
> > > > Oracle has security at the OS and Database level. All I can find from
> > > > Informix is that they only have security at the OS level. SO, if you
> > have
> > > > root privileges for the OS, you can get into the tables of our product
> > > > (which, obviously we dont want to happen).
> > >
Yuri
is very high it is always possible to huck into the level of DB schema. And if
patented it will be harder to steal.
Yuri.
Greg Starnes wrote:
> Informix Dynamic Server 9.3
>
> Ok, I am a converted oracle dork, so most of my posts start with: I know
> Oracle does this. This is bad because i really like Informix (I truely am a
> glutton for punishment).
>
> Oracle has security at the OS and Database level. All I can find from
> Informix is that they only have security at the OS level. SO, if you have
> root privileges for the OS, you can get into the tables of our product
> (which, obviously we dont want to happen).
>
> I work in a software development environment. We are creating an accounting
> product with a java front end, and an Informix back-end, which will be
> installed to a clients server via our Post sales support team. We've worked
> long and hard to get the DB model to where it is. If someone can get into
Ben Draper
Won't they have a DBA who knows the system or sys account passwords?
Once you know those, your in regardless of what other account privileges you
set up.
Greg Starnes wrote in message <8ea9k0$kv5$1...@paxfeed.eni.net>...
Greg Starnes
what everyone said: the schema should be open. People can get to it if
they really wanted to anyways. But who would care. Im SURE that none of
you would. I was really looking for fuel to tell my bosses what they want
really won't work. This string of posts will do the trick VERY WELL!!
Thanks again.
Greg
"Greg Starnes" <gsta...@ep-services.com> wrote in message
news:8e9vi3$ei3$1...@paxfeed.eni.net...
Art S. Kagel
the priveleges user or role specific. This will give you even better
protection than Oracle.
Art S. Kagel
Steven Hauser
exp full=yes rows=no file=schema.dmp
will give you the complete schema including spl, triggers, etc
so what is so secure about oracle?
Daniel Wood
> All database information is stored in binary format and isn't easily (or
> feasibly) readable. Also, root doesn't have any special
> privileges; he/she is just like any user and needs to be granted access.
> But, as with Oracle, root can *become* any user - there's no database
> that can get around that.
I believe Oracle has "database users" which are NOT system users. These db users
connect
with a user name and password which are not in /etc/passwd hence you can NOT su to
them. The
database maintains the list of valid db users and passwd's who can connect. If
they used canned
applications which connected to the database you wouldn't see the passwd they
used. This was
the point being made. However, hard coded passwords in executables are easy to
find even if
scrambled.
> > It would be easy to write a utility to dump the system catalog information.
>
> Nope. See above.
Once I was at a company where the Altos Unix OS panicked whenever an Informix
archive
was done. I had no access to and had never seen Unix source code but I hand
patched in a
stack backtrace routine, in machine code, into the routine which prints kernal
messages.
From this I disassembled the routine which invoked the panic and reverse engineered
it into
pseudo C code. I studied the function and discovered the bug which I was then able
to convince
Altos that they had in their kernal. Previous attempts at dealing with Altos tech.
support were
useless.
If this is a 10 then figuring out the structure of rows which hold the column
names, types, etc.
is about a 2. I assume Oracle's documenation is decent. Long before I came to
Informix the
information in the 5X Informix DBA manual gave me enough info. to write code to
read and
interpret the raw database instance. If Oracle's documentation is poor then maybe
it's a 3
on the scale of 1 to 10 in difficultly.
and, Heck!, I just work in tech. support.
Madison Pruet
"Ron M. Flannery" wrote:
> On Fri, 28 Apr 2000, Daniel Wood wrote:
>
> > So exactly how does database permissions prevent a user with root access
> > from directly reading the catalog information from the disk bypassing the
> > database engine. Unless encrypted this would be trivial. I believe Oracle
> > does document the layout of their disk structures.
>
> All database information is stored in binary format and isn't easily (or
> feasibly) readable. Also, root doesn't have any special
> privileges; he/she is just like any user and needs to be granted access.
> But, as with Oracle, root can *become* any user - there's no database
> that can get around that.
>
> >
> > It would be easy to write a utility to dump the system catalog information.
>
> Nope. See above.
Wanna bet?.... ;-)
I've debugged stuff without source code before. I've found bugs in other vendor's
compilers based on the generated binary. Also, I've written utilities to format and
intreprete stuff in binary format without any documentation. I'm not all that smart
either - just stubborn.
Also don't forget how Compact Computer got started. They reverse engineered the IBM
PC and in order to legally do that, they had to use engineers that knew absolutly
nothing about the IBM PC. Now just imagine how few really good engineers there were
at the time that had absolutly no knowledge about the IBM PC, including having never
even seen one. Remember at the time it was the neatest 'hot stuff'.
>
> >
> > I don't want to argue which product is superior but I will say that having
> > a feature that provides a false sense of security does not make any product
> > superior.
>
> Any user that can access the data needs a valid login ID. If the database
> administrator takes proper care, you should be safe.
>
> - Ron F.
>
> ________________________________________________________________________
> Ron Flannery <mailto:rfla...@informixhandbook.com>, 248-887-8470x40
>
> Lead author, Informix Handbook President, One Point Solutions
> "Your Complete Reference" "Informix & Web/Database solutions"
> http://www.informixhandbook.com http://www.one-point.com
> ________________________________________________________________________
> >
> > Greg Starnes wrote:
> >
> > > My problem is that were using Informix for the back-end of a software
> > > package we are selling. Most of the value of this product is in the schema
> > > of the tables. If we set up this package on our clients computer (who will
> > > have root privelidges on the OS), they can go in and steal the layout of the
> > > tables.
> > >
> > > With Oracle, there is security at the DB level, so we can preset the
> > > privelidges on the tables, so that they cant get into them and rip them off
> > > (ie. take the schema and use it to set up thier own accounting dept (we are
> > > building an accounting package)).
> > >
> > > Am I going to have to tell my boss that Oracle is in fact superior... This
> > > could be a deal breaker for Informix, and I'd love to NOT see that happen.
> > >
> > > Thanks for your comments, it raises some interesting questions for our web
> > > server.
> > >
> > > "David Stes" <st...@pandora.be> wrote in message
> > > news:3908A205...@pandora.be...
> > > > Greg Starnes wrote:
> > > > >
> > > > > Oracle has security at the OS and Database level. All I can find from
> > > > > Informix is that they only have security at the OS level. SO, if you
> > > have
> > > > > root privileges for the OS, you can get into the tables of our product
> > > > > (which, obviously we dont want to happen).
> > > >
> > > > Having security at both os and database level seems complex.
> > > >
> > > > I like the Informix simplicity of having only OS level security.
> > > >
> > > > There's also a risk of duplication, where the database would implement
> > > > services that can/are better provided by the OS.
> > > >
> > > > Maybe there exists for example a "crypto-filesystem" where the
> > > > read/write's to files would be encrypted so you could have a layer of
> > > > security (provided by the OS) like that.
> > > >
> > > > But I also sometimes worry about Informix security.
> > > >
> > > > Wouldn't informix SE security for Linux (I use SE, I don't know about
> > > > Dynamic) be improved, by implementing communication IPC through simple
> > > > pipes ?
> > > >
> > > > I don't need the remote capabilities of "sesoctcp" and I think both
> > > > security and performance could be better if communication through pipes
> > > > (seipcpip?) were supported.
> > > >
> > > > This is something that I worry about, that the informix daemon is
> > > > listening on a socket and would accept connections; I'd rather have it
> > > > listen only on a domain socket or pipe, but I don't think there's a way
> > > > to do it right now.
> >
--
Madison Pruet
===========================================
Enterprise Replication Product Developement
Dallas, Texas
Informix Software
===========================================
Paul Brown
Madison Pruet wrote:
> See below....
>
> "Ron M. Flannery" wrote:
>
> > On Fri, 28 Apr 2000, Daniel Wood wrote:
> > > It would be easy to write a utility to dump the system catalog information.
> >
> > Nope. See above.
>
> Wanna bet?.... ;-)
>
> I've debugged stuff without source code before. I've found bugs in other vendor's
> compilers based on the generated binary. Also, I've written utilities to format and
> intreprete stuff in binary format without any documentation. I'm not all that smart
> either - just stubborn.
Arrrrr! You guys are pussies!
I once debugged a database by hooking wires up between the
memory bus and my nipples with alligator clips! Then the "patch" required
that I pee on the mother board to burn a new shunt. (Had to drink a whole
case of Mountain Dew to get the acidity right!)
David Williams
<paul.N...@informix.com> writes
>
>
> Arrrrr! You guys are pussies!
>
> I once debugged a database by hooking wires up between the
> memory bus and my nipples with alligator clips! Then the "patch" required
> that I pee on the mother board to burn a new shunt. (Had to drink a whole
> case of Mountain Dew to get the acidity right!)
>
Don't worry, help is on the way...I'll just need to mount the extra
large dart gun on top of the truck first...
--
David Williams
Ron M. Flannery
> >
> > All database information is stored in binary format and isn't easily (or
> > feasibly) readable. Also, root doesn't have any special
> > privileges; he/she is just like any user and needs to be granted access.
> > But, as with Oracle, root can *become* any user - there's no database
> > that can get around that.
> >
> > >
> >
> > Nope. See above.
>
> Wanna bet?.... ;-)
>
> I've debugged stuff without source code before. I've found bugs in other vendor's
> compilers based on the generated binary. Also, I've written utilities to format and
> intreprete stuff in binary format without any documentation. I'm not all that smart
> either - just stubborn.
>
> PC and in order to legally do that, they had to use engineers that knew absolutly
> nothing about the IBM PC. Now just imagine how few really good engineers there were
> at the time that had absolutly no knowledge about the IBM PC, including having never
> even seen one. Remember at the time it was the neatest 'hot stuff'.
Okay, but remember that I said "isn't EASILY accessible." If we get to
the level of reverse engineering the Informix data, then why wouldn't the
model apply to Oracle or anyone else for that matter? I think that's how
this whole thread got started, anyway. My point was that Informix
requires a valid system login ID and is further controlled at the database
level. If these things are properly controlled by the system and Informix
administrator, you should have no problems.
Obnoxio The Clown
From: Paul Brown <paul.N...@informix.com>
>
>Madison Pruet wrote:
>
> > See below....
> >
> > "Ron M. Flannery" wrote:
> >
> > > On Fri, 28 Apr 2000, Daniel Wood wrote:
>information.
> > >
> > > Nope. See above.
> >
> > Wanna bet?.... ;-)
> >
> > I've debugged stuff without source code before. I've found bugs in other
>vendor's
> > compilers based on the generated binary. Also, I've written utilities
>to format and
> > intreprete stuff in binary format without any documentation. I'm not all
>that smart
> > either - just stubborn.
>
>
> I once debugged a database by hooking wires up between the
> memory bus and my nipples with alligator clips! Then the "patch"
>required
> that I pee on the mother board to burn a new shunt. (Had to drink a
>whole
> case of Mountain Dew to get the acidity right!)
That's nothing... I once had to install Oracle... :0)
Mark D. Stock
Paul Brown wrote:
>
> Madison Pruet wrote:
>
> > See below....
> >
> > "Ron M. Flannery" wrote:
> >
> > > On Fri, 28 Apr 2000, Daniel Wood wrote:
> > > > It would be easy to write a utility to dump the system catalog information.
> > >
> > > Nope. See above.
> >
> > Wanna bet?.... ;-)
> >
> > I've debugged stuff without source code before. I've found bugs in other vendor's
> > compilers based on the generated binary. Also, I've written utilities to format and
> > intreprete stuff in binary format without any documentation. I'm not all that smart
> > either - just stubborn.
>
> Arrrrr! You guys are pussies!
>
> I once debugged a database by hooking wires up between the
> memory bus and my nipples with alligator clips! Then the "patch" required
> that I pee on the mother board to burn a new shunt. (Had to drink a whole
> case of Mountain Dew to get the acidity right!)
Ya give the Guy the weekend off and he just can't handle it! :-)
Cheers,
--
Mark.
+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mds...@mydas.freeserve.co.uk |//////// /|
| http://www.informix.com http://www.informixhandbook.com |///// / //|
| http://www.iiug.org +-----------------------------------+//// / ///|
| |What year 2000 bug? year 2000 bug? |/// / ////|
| |year 2000 bug? year 2000 bug? year |// / /////|
| |2000 bug? year 2000 bug? year 1900 |/ ////////|
+----------------------+-----------------------------------+-----------+
Paul Watson
[cutting]
>> Arrrrr! You guys are pussies!
>>
>> I once debugged a database by hooking wires up between the
>> memory bus and my nipples with alligator clips! Then the "patch"
>>required
>> that I pee on the mother board to burn a new shunt. (Had to drink a
>>whole
>> case of Mountain Dew to get the acidity right!)
>
Amateur, I once had to try and get it stable :0)
Paul Watson #
WFSoftware Ltd # All answers given
Tel: +44 1436 674729 # are pure fantasy
Fax: +44 1436 678693 #
www.wfsoftware.com/informix #
Art S. Kagel
>
> [cutting]
> >> Arrrrr! You guys are pussies!
> >>
> >> I once debugged a database by hooking wires up between the
> >> memory bus and my nipples with alligator clips! Then the "patch"
> >>required
> >> that I pee on the mother board to burn a new shunt. (Had to drink a
> >>whole
> >> case of Mountain Dew to get the acidity right!)
> >
> >That's nothing... I once had to install Oracle... :0)
>
> Amateur, I once had to try and get it stable :0)
Now for something REALLY scary: I once had to USE Oracle! :^)
Art S. Kagel
mars...@my-deja.com
I got ya all beat. I once had to call Oracle for support for their
development system!
Several times, actually... They never did figure it out...
--
# unrm /
ksh: unrm: not found
# man cpio
Paul Watson
>> Paul Watson wrote:
>> >
>> > [cutting]
>> > >> Arrrrr! You guys are pussies!
>> > >>
>> > >> I once debugged a database by hooking wires up between the
>> > >> memory bus and my nipples with alligator clips! Then the
"patch"
>> > >>required
>> > >> that I pee on the mother board to burn a new shunt. (Had to
drink a
>> > >>whole
>> > >> case of Mountain Dew to get the acidity right!)
>> > >
>> > >That's nothing... I once had to install Oracle... :0)
>> >
>> > Amateur, I once had to try and get it stable :0)
>>
>> Now for something REALLY scary: I once had to USE Oracle! :^)
>>
>> Art S. Kagel
>>
>
>I got ya all beat. I once had to call Oracle for support for their
>development system!
>
OK you win, nobody should have to do that
Paul Watson #
WFSoftware Ltd # Things Are Going to
Tel: +44 1436 674729 # Get a Lot Worse
Fax: +44 1436 678693 # Before Things Get Worse
www.wfsoftware.com/informix #
DNP
newsgroup?
Just because you can't get Oracle to run the way you like, are you
seriously blaming Oracle for this!!!
What's really scary is the thought that you might be doing just that!
Bet you argue with the sun coming up (It's too early for you to rise !!!
It says so on my watch!!)
Art S. Kagel
mars...@my-deja.com wrote:
>
> In article <390EE329...@bloomberg.net>,
> ka...@bloomberg.net wrote:
> > Paul Watson wrote:
> > >
> > > [cutting]
> > > >> Arrrrr! You guys are pussies!
> > > >>
> > > >> I once debugged a database by hooking wires up between the
> > > >> memory bus and my nipples with alligator clips! Then the
> "patch"
> > > >>required
> > > >> that I pee on the mother board to burn a new shunt. (Had to
> drink a
> > > >>whole
> > > >> case of Mountain Dew to get the acidity right!)
> > > >
> > > >That's nothing... I once had to install Oracle... :0)
> > >
> > > Amateur, I once had to try and get it stable :0)
> >
> > Now for something REALLY scary: I once had to USE Oracle! :^)
> >
> > Art S. Kagel
> >
>
> I got ya all beat. I once had to call Oracle for support for their
> development system!
>
> Several times, actually... They never did figure it out...
The only times I've called and they actually figured ANYTHING out I got a
FAX of a workaround that was two years old! It solved the problem but my
question is: Why was the bug not fixed in two years?
Art S. Kagel