I must agree with Doug Chamberlin. We put out an application the goes on
service countertops at auto and truck service centers. Our worry is not
that some IT professional or a skilled hacker will attempt to break into it,
but the common user attempting to extract the data. This can happen when a
manager attempts to get a deal from a competitor and offers our data for
their product as an incentive . And no, we can't keep the data on the web
as most service centers do not have web access. We provide this program as
a convenience to our customers for providing our parts to replace competitor
parts and do not wish to make it simple for them to reciprocate.


-----Original Message-----
From: IB-Architect@egroups.com [mailto:IB-Architect@egroups.com]
Sent: Tuesday, May 30, 2000 11:52 AM
To: IB-Architect@egroups.com
Subject: [IB-Aritect] Digest Number 83


------------------------------------------------------------------------
Failed tests, classes skipped, forgotten locker combinations.
Remember the good 'ol days
http://click.egroups.com/1/4053/4/_/830676/_/959705496/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com


------------------------------------------------------------------------

There are 25 messages in this issue.

Topics in this digest:

1. Re: Fw: Mischievous SYSDBA
From: Benny Schaich <b.schaich@...>
2. Re: Fw: Mischievous SYSDBA
From: Paul Reeves <paul@...>
3. Re: Fw: Mischievous SYSDBA
From: Doug Chamberlin <dchamberlin@...>
4. Re: Fw: Mischievous SYSDBA
From: Benny Schaich <b.schaich@...>
5. Re: Fw: Mischievous SYSDBA
From: Paul Reeves <paul@...>
6. Re: Fw: Mischievous SYSDBA
From: Benny Schaich <b.schaich@...>
7. Sorry, this went through double
From: Benny Schaich <b.schaich@...>
8. Re: Fw: Mischievous SYSDBA
From: Jim Starkey <jas@...>
9. Security Worklist
From: Jim Starkey <jas@...>
10. SuperServer vs. Classic
From: Jim Starkey <jas@...>
11. Re: Fw: Mischievous SYSDBA
From: Tim Uckun <tim@...>
12. RE: SuperServer vs. Classic
From: "Leyne, Sean" <InterbaseArchitecture@...>
13. Re: Fw: Mischievous SYSDBA
From: Jim Starkey <jas@...>
14. RE: Fw: Mischievous SYSDBA
From: "Leyne, Sean" <InterbaseArchitecture@...>
15. Re: SuperServer vs. Classic
From: "Jason Chapman" <jason@...>
16. Re: SuperServer vs. Classic
From: Dalton Calford <dcalford@...>
17. Re: Fw: Mischievous SYSDBA
From: Tim Uckun <tim@...>
18. RE: Fw: Mischievous SYSDBA
From: Tim Uckun <tim@...>
19. Re: Fw: Mischievous SYSDBA
From: Dalton Calford <dcalford@...>
20. Re: SuperServer vs. Classic
From: "Markus Kemper" <mkemper@...>
21. RE: SuperServer vs. Classic
From: "Leyne, Sean" <InterbaseArchitecture@...>
22. RE: SuperServer vs. Classic
From: "Leyne, Sean" <InterbaseArchitecture@...>
23. New API -- Request for Comments
From: Jim Starkey <jas@...>
24. Re: Fw: Mischievous SYSDBA
From: Jim Starkey <jas@...>
25. Fw: Mischievous SYSDBA
From: David Schnepper <dave@...>


________________________________________________________________________
________________________________________________________________________

Message: 1
Date: Tue, 30 May 2000 11:29:02 +0200
From: Benny Schaich <b.schaich@...>
Subject: Re: Fw: Mischievous SYSDBA

Jim,

having talked to many IB customers in the past I think I know what the
problem is
here.

Those customers are mostly coming from desktop databases like paradox
and dBase,
where such an encryption existed - and could be broken anyway (like for
pdx you
can find a general password in the internet, hacked by some russian
programmer).

The problem is, that this is in the brains of people and even if you
tell them
it's unsecure they will insist this is better then nothing. They always
have this
horror, that their valued data is delivered on disk, non coded and can
be viewed
to anyone just using a disk editor. This is an irrational fear but
believe me,
it's much less work just implementing something then discussing this
over and
over again. This is a marketing feature, nothing else.

I know what hurts you deeply here, but this is one of the occasions
where its
better to have a "me to" on the feature list - knowing it is useless.

Best Regards,
Benny


Jim Starkey schrieb:

> At 11:04 PM 5/25/00 +0200, Steve Tendon wrote:
> >
> >Don't get me wrong: I'm not advocating "security-thru-obscurity".

However, I

> >still don't feel we're getting any closer to a solution.
> >
>
> Steve, could you take a few minutes to describe exactly what the
> problem is, what the requirements for a solution might be, what
> VARs are currently doing with InterBase, and if you happen to
> know, what VARs are doing about the problem with other database
> systems?
>

________________________________________________________________________
________________________________________________________________________

Message: 2
Date: Tue, 30 May 2000 12:01:09 +0200
From: Paul Reeves <paul@...>
Subject: Re: Fw: Mischievous SYSDBA

Benny Schaich wrote:

>
> I know what hurts you deeply here, but this is one of the occasions
> where its
> better to have a "me to" on the feature list - knowing it is useless.
>

This is sort of an aside, but...

Given that something like that goes in, how do we flag it up as being froth?


I don't mind bright marketing ideas as long as they are obviously just that.
One
requirement should be that a reasonable developer can evaluate such a
'feature'
in half an hour and discard it as useless.

After all, some people will actually go away and try building a solution
using
it. Still, it might help in technical support - separate the idiots from
those
that know what they are doing. The 'walk and chew gum' test?

Paul
--

Paul Reeves
Fleet River Software



________________________________________________________________________
________________________________________________________________________

Message: 3
Date: Tue, 30 May 2000 06:51:18 -0400
From: Doug Chamberlin <dchamberlin@...>
Subject: Re: Fw: Mischievous SYSDBA

At 5/30/00 06:01 AM (Tuesday), Paul Reeves wrote:

>I don't mind bright marketing ideas as long as they are obviously just
>that. One
>requirement should be that a reasonable developer can evaluate such a
>'feature'
>in half an hour and discard it as useless.
>
>After all, some people will actually go away and try building a solution

using

>it. Still, it might help in technical support - separate the idiots from

those

>that know what they are doing. The 'walk and chew gum' test?

Sorry, folks, but I've had just about enough of this purist nonsense. The
above comment says that if Interbase was to have an encryption scheme built
in which is not absolutely secure in that it can be broken with some effort
that it would be "useless". The next paragraph says that someone might
actually depend on this encryption and if they do they clearly will not
know what they are doing.

I say rubbish! We have all talked on and on about how "security through
obscurity is not really security". Ok, from a purist viewpoint it is not.
However, there is plenty of value in a security scheme based on obscurity.
They have protected many systems I have used for many years. Sure, they can
be cracked with a bit of effort but the point is to raise the bar so the
level of effort is more than the target audience will attempt. It works.

Now, doing this does not make me an idiot. I do it fully recognizing the
situation. it is a business decision just like all business decisions which
involve trade offs.

Several Interbase users have requested some type of encryption so that they
can have some type of security through obscurity because they find doing
nothing unacceptable. Jim's (and other's) response has been basically
"Well, you understand that you are not really getting full security,
right?" Their response to that has been "Yes, we understand but we need it
anyway!" There are no idiots here!

I fully support activating the mechanism for encrypting data in the GDB
files. If some developer then goes and places too much reliance on it,
thinking it is an absolutely secure mechanism, then that it their
responsibility. ALl we have is a documentation problem which points out the
shortcomings of the feature.



________________________________________________________________________
________________________________________________________________________

Message: 4
Date: Tue, 30 May 2000 14:43:35 +0200
From: Benny Schaich <b.schaich@...>
Subject: Re: Fw: Mischievous SYSDBA


Jim,

having talked to many IB customers in the past I think I know what the
problem is
here.

Those customers are mostly coming from desktop databases like paradox
and dBase,
where such an encryption existed - and could be broken anyway (like for
pdx you
can find a general password in the internet, hacked by some russian
programmer).

The problem is, that this is in the brains of people and even if you
tell them
it's unsecure they will insist this is better then nothing. They always
have this
horror, that their valued data is delivered on disk, non coded and can
be viewed
to anyone just using a disk editor. This is an irrational fear but
believe me,
it's much less work just implementing something then discussing this
over and
over again. This is a marketing feature, nothing else.

I know what hurts you deeply here, but this is one of the occasions
where its
better to have a "me to" on the feature list - knowing it is useless.

Best Regards,
Benny


Jim Starkey schrieb:

> At 11:04 PM 5/25/00 +0200, Steve Tendon wrote:
> >
> >Don't get me wrong: I'm not advocating "security-thru-obscurity".

However, I

> >still don't feel we're getting any closer to a solution.
> >
>
> Steve, could you take a few minutes to describe exactly what the
> problem is, what the requirements for a solution might be, what
> VARs are currently doing with InterBase, and if you happen to
> know, what VARs are doing about the problem with other database
> systems?
>

________________________________________________________________________
________________________________________________________________________

Message: 5
Date: Tue, 30 May 2000 14:33:22 +0200
From: Paul Reeves <paul@...>
Subject: Re: Fw: Mischievous SYSDBA

Doug Chamberlin wrote:

>
> Sorry, folks, but I've had just about enough of this purist nonsense.
>

I don't know about purism, but if a feature is going to go into InterBase it
should work as expected and its purpose be clearly documented. If a feature
is
added purely to suit a perceived marketing gap then its utility is, from a
development pov, questionable.

How are developers meant to know which bit is for the comfort of senior
management and which bits are for real? How do you allocate InterBase
development and QA time for such features? Do they get as much as
enhancements
that are really necessary for the engine? If not, then how reliable are
they?

This thread is largely circular. A need for better overall security of the
database is acknowledged. No credible proposition has yet been tabled to
address
it (tell me I'm wrong), that hasn't had numerous shortcomings exposed. And
around it goes again.

I may have got all this wrong, but InterBase primarily sells itself on
technical
merit. Technical merit gives marketing something to work with. When
marketing
imperatives drive development InterBase will be a different product.

And in my previous thread I made absolutely no reference to the value of a
cod
encryption scheme. The suggestion was made that encryption be added largely
because it would address a marketing shortcoming. I was discussing the value
of
'purely marketing features' from a development standpoint. It was in the
context
of this thread, admittedly, but I did prefix my comments with 'This is sort
of
an aside...'

> ALl we have is a documentation problem which points out the
> shortcomings of the feature.
>

Exactly.

Bullet point - InterBase supports data encryption.

Documentation extract - Do a, b and c to encrypt your database. It'll run
slower
and any competent developer will be able to break it with a quick hack in
five
minutes (but don't tell management).


I don't think it is purism to be unable to take this seriously, however good
an
idea it sounds. And if one starts putting such 'features' into the engine
then
how seriously must we take people who use them? Obviously very seriously
indeed.


Paul
--

Paul Reeves
Fleet River Software



________________________________________________________________________
________________________________________________________________________

Message: 6
Date: Tue, 30 May 2000 15:32:58 +0200
From: Benny Schaich <b.schaich@...>
Subject: Re: Fw: Mischievous SYSDBA



Paul Reeves schrieb:

> Given that something like that goes in, how do we flag it up as being

froth?

>

Very easy: Write it into the manual <g>.
The point is, that it takes much effort to explain somebody why we don't do
what he
wishes. This always looks like bad customer service -no matter what. Once
you
implement such service it is eligible for the customer to use. To use it she
needs
to read your manual -and there you can explain in epical wideness (hope this
translates well to english) why you think this is a feature that should not
be used.

This is what I call extremely good customer service.

> One requirement should be that a reasonable developer can evaluate such a
> 'feature'
> in half an hour and discard it as useless.

By Reading the manual in two minutes? <g>

> Still, it might help in technical support - separate the idiots from those
> that know what they are doing. The 'walk and chew gum' test?

You see, another reason why I like open source: You don't need to care how
you talk
about your customers in public ;-)



Benny



________________________________________________________________________
________________________________________________________________________

Message: 7
Date: Tue, 30 May 2000 15:38:31 +0200
From: Benny Schaich <b.schaich@...>
Subject: Sorry, this went through double




[Non-text portions of this message have been removed]



________________________________________________________________________
________________________________________________________________________

Message: 8
Date: Tue, 30 May 2000 09:46:37 -0400
From: Jim Starkey <jas@...>
Subject: Re: Fw: Mischievous SYSDBA

At 06:51 AM 5/30/00 -0400, Doug Chamberlin wrote:

>>that know what they are doing. The 'walk and chew gum' test?
>
>Sorry, folks, but I've had just about enough of this purist nonsense. The
>above comment says that if Interbase was to have an encryption scheme built

>in which is not absolutely secure in that it can be broken with some effort

>that it would be "useless". The next paragraph says that someone might
>actually depend on this encryption and if they do they clearly will not
>know what they are doing.
>

Going back to the beginning, I think we have established two things.
First, there is a perceived problem. Second, encryption isn't the
answer.

There are lots of ways to solve most problems, but only if the
problem is well understood. So, once again, could somebody make
a stab at a clear problem definition. Not a prospective solution --
just the problem.

If the problem is just hiding the data, a solution could be
a mechanism to take part of the database offline, either in a
separate self describing file or just marked inaccessible. A
sanctioned application program could do something to activate
the offline piece when it needed access. Or, if it is in
a separate file, decrypt it before attaching and re-encrypt
it at end.

Or maybe a simple scheme to XOR a pattern across a page before
writing and after reading, with the pattern passed in as an
attach parameter (not secure, but it does get the job done).

Maybe a beef up of the external file mechanism would suffice...

If the data is numeric, maybe nothing is needed. Compressed
binary data is pretty close to gobbledy-gook.

Maybe something fancier than run length encoding would provide
the obscurity and give better compression to boot (the current
scheme was chosen to be kind to the slow computers we had in
1984). Ever look at a zip file in an editor?

Hey, guys, ideas are cheap. The hard part is figuring out the
boundaries of the problem.

Jim Starkey


________________________________________________________________________
________________________________________________________________________

Message: 9
Date: Tue, 30 May 2000 09:55:38 -0400
From: Jim Starkey <jas@...>
Subject: Security Worklist

At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:

>
>An abbreviated list of what I believe needs to be done: On NT an Interbase
>server should run under an non-privileged account, and all the databases
>should be ACLd to only be readable by that account. On Unix systems it
>should run as a non-root user in a chrooted gaol, again with correct
>permissions. The database paths should be administrator configured on the
>server and not accepted from clients. The local protocol should be ignored
>(or removed) until it is fixed. For single user applications, the server
>should be able to run in an application process context, and therefore be
>the restrictions of the user's account. The server should only listen for
>connections on administrator specified ports and interfaces, with specified
>rules for acceptable connections. isc4.gdb should die. &c.
>
>You can configure an Interbase server to close the most obvious holes in an
>installation; it has been discussed on this and other lists. Developers
>just need to apply their brains, and fix their installation procedures.
>Today, as always, an application developer must provide instructions for
>installing a piece of software securely. It is no one else's
>responsibility. If the developer can't do that, they deserve everything
>they get, and helping them to attempt to pull the wool over everyone's eyes
>doesn't do anyone any good.
>

This seems like an excellent set of marching orders for 6.1.

Jim Starkey


________________________________________________________________________
________________________________________________________________________

Message: 10
Date: Tue, 30 May 2000 10:20:21 -0400
From: Jim Starkey <jas@...>
Subject: SuperServer vs. Classic

At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:

>
>All this applies to superserver, of course. Classic should just be taken
>into the woods and shot.
>

This is the single most difficult and important question facing future
development. Among the issues:

1. SuperServer only works on threaded platforms.
2. Security is hopeless in Classic
3. The conditionalization of the code makes ongoing maintenance
of two branches highly problematic.
4. Support both on the same machine borders on impossible
5. Given an abstract workload, neither is a clear winner.
Given a specific workload, one will generally outshine
the other.
6. Asking the using at installation time which to install
time is problematic -- how could a new use possible make
an intelligent decision.

An argument can me made -- but I haven't convinced Charlie -- that
removing Classic will speed up SuperServer (algorithms are now chosen
that work well in both), and that speeding up SuperService is necessary
to kill off Classic. Chicken, egg.

Thoughts?

Jim Starkey


________________________________________________________________________
________________________________________________________________________

Message: 11
Date: Tue, 30 May 2000 08:37:48 -0600
From: Tim Uckun <tim@...>
Subject: Re: Fw: Mischievous SYSDBA

At 09:46 AM 5/30/00 -0400, you wrote:

>There are lots of ways to solve most problems, but only if the
>problem is well understood. So, once again, could somebody make
>a stab at a clear problem definition. Not a prospective solution --
>just the problem.

I don't want to speak for everybody but here is my wish in a nutshell.

There ought to exists a mechanism such that only the application I have
written should have any access to the data and schema.


That's it. The file ought to be utterly useless to anything and anybody
other then my application. My application will interact with the data and
show the results to my customer if, where, when and how I want.
----------------------------------------------
Tim Uckun
Mobile Intelligence Unit.
----------------------------------------------
"There are some who call me TIM?"
----------------------------------------------


________________________________________________________________________
________________________________________________________________________

Message: 12
Date: Tue, 30 May 2000 10:43:03 -0400
From: "Leyne, Sean" <InterbaseArchitecture@...>
Subject: RE: SuperServer vs. Classic


A couple of questions before my vote.

-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Tuesday, May 30, 2000 10:20 AM
To: IB-Architect@egroups.com
Subject: [IB-Architect] SuperServer vs. Classic

At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:

>
>All this applies to superserver, of course. Classic should just be

taken

>into the woods and shot.
>

This is the single most difficult and important question facing future
development. Among the issues:

1. SuperServer only works on threaded platforms.

Which platforms would this eliminate?

2. Security is hopeless in Classic
3. The conditionalization of the code makes ongoing maintenance
of two branches highly problematic.
4. Support both on the same machine borders on impossible
5. Given an abstract workload, neither is a clear winner.
Given a specific workload, one will generally outshine
the other.

Can you give some example workloads?

6. Asking the using at installation time which to install
time is problematic -- how could a new use possible make
an intelligent decision.

An argument can me made -- but I haven't convinced Charlie -- that
removing Classic will speed up SuperServer (algorithms are now chosen
that work well in both), and that speeding up SuperService is necessary
to kill off Classic. Chicken, egg.

Thoughts?

Jim Starkey

------------------------------------------------------------------------
Failed tests, classes skipped, forgotten locker combinations.
Remember the good 'ol days
http://click.egroups.com/1/4053/4/_/830676/_/959696797/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com




________________________________________________________________________
________________________________________________________________________

Message: 13
Date: Tue, 30 May 2000 10:42:02 -0400
From: Jim Starkey <jas@...>
Subject: Re: Fw: Mischievous SYSDBA

At 08:37 AM 5/30/00 -0600, Tim Uckun wrote:

>
>There ought to exists a mechanism such that only the application I have
>written should have any access to the data and schema.
>
>
>That's it. The file ought to be utterly useless to anything and anybody
>other then my application. My application will interact with the data and
>show the results to my customer if, where, when and how I want.

Is the application restricted to the native InterBase API? Or must
the solution work with ODBC, JDBC, BDE, etc? Does there need to
be an escape for third party report writers, etc? Do you need
to be able to back it up?

What threats should the mechanism reasonable protect against? A
well meaning but misadvised user? An application program wanting
to write an extension? A competing developer?

Jim Starkey


________________________________________________________________________
________________________________________________________________________

Message: 14
Date: Tue, 30 May 2000 10:46:19 -0400
From: "Leyne, Sean" <InterbaseArchitecture@...>
Subject: RE: Fw: Mischievous SYSDBA

Tim,

And what about legitimate access via third party software??? [Excel via
ODBC, Crystal Reports via OLE DB, Cognos PowerPlay 7.0 by native
connection (we can hope)].


Sean

-----Original Message-----
From: Tim Uckun [mailto:tim@...]
Sent: Tuesday, May 30, 2000 10:38 AM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] Fw: Mischievous SYSDBA

At 09:46 AM 5/30/00 -0400, you wrote:

>There are lots of ways to solve most problems, but only if the
>problem is well understood. So, once again, could somebody make
>a stab at a clear problem definition. Not a prospective solution --
>just the problem.

I don't want to speak for everybody but here is my wish in a nutshell.

There ought to exists a mechanism such that only the application I have

written should have any access to the data and schema.


That's it. The file ought to be utterly useless to anything and anybody
other then my application. My application will interact with the data
and
show the results to my customer if, where, when and how I want.
----------------------------------------------
Tim Uckun
Mobile Intelligence Unit.
----------------------------------------------
"There are some who call me TIM?"
----------------------------------------------

------------------------------------------------------------------------
Was the salesman clueless? Productopia has the answers.
http://click.egroups.com/1/4633/4/_/830676/_/959697344/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com




________________________________________________________________________
________________________________________________________________________

Message: 15
Date: Tue, 30 May 2000 16:10:33 +0100
From: "Jason Chapman" <jason@...>
Subject: Re: SuperServer vs. Classic

If Superserver worked on SMP would there be any reason for keeping classic?

Are there any environments that just won't support Superserver?

For my needs: >350 concurrent users - so classic is out, but SMP would be a
great benefit.

JAC.

----- Original Message -----
From: Jim Starkey <jas@...>
To: <IB-Architect@egroups.com>
Sent: 30/mm/2000 3:20 PM
Subject: [IB-Architect] SuperServer vs. Classic


> At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:
> >
> >All this applies to superserver, of course. Classic should just be taken
> >into the woods and shot.
> >
>
> This is the single most difficult and important question facing future
> development. Among the issues:
>
> 1. SuperServer only works on threaded platforms.
> 2. Security is hopeless in Classic
> 3. The conditionalization of the code makes ongoing maintenance
> of two branches highly problematic.
> 4. Support both on the same machine borders on impossible
> 5. Given an abstract workload, neither is a clear winner.
> Given a specific workload, one will generally outshine
> the other.
> 6. Asking the using at installation time which to install
> time is problematic -- how could a new use possible make
> an intelligent decision.
>
> An argument can me made -- but I haven't convinced Charlie -- that
> removing Classic will speed up SuperServer (algorithms are now chosen
> that work well in both), and that speeding up SuperService is necessary
> to kill off Classic. Chicken, egg.
>
> Thoughts?
>
> Jim Starkey
>
> ------------------------------------------------------------------------
> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/4/_/830676/_/959696797/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>



________________________________________________________________________
________________________________________________________________________

Message: 16
Date: Tue, 30 May 2000 11:30:41 -0400
From: Dalton Calford <dcalford@...>
Subject: Re: SuperServer vs. Classic

I personally would not want to see the classic version dropped until
supersever supports threads that work across processors (and by
extension accross machines in beowolf type constructs).

best regards

Dalton

Jim Starkey wrote:
>
> At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:
> >
> >All this applies to superserver, of course. Classic should just be taken
> >into the woods and shot.
> >
>
> This is the single most difficult and important question facing future
> development. Among the issues:
>
> 1. SuperServer only works on threaded platforms.
> 2. Security is hopeless in Classic
> 3. The conditionalization of the code makes ongoing maintenance
> of two branches highly problematic.
> 4. Support both on the same machine borders on impossible
> 5. Given an abstract workload, neither is a clear winner.
> Given a specific workload, one will generally outshine
> the other.
> 6. Asking the using at installation time which to install
> time is problematic -- how could a new use possible make
> an intelligent decision.
>
> An argument can me made -- but I haven't convinced Charlie -- that
> removing Classic will speed up SuperServer (algorithms are now chosen
> that work well in both), and that speeding up SuperService is necessary
> to kill off Classic. Chicken, egg.
>
> Thoughts?
>
> Jim Starkey
>
> ------------------------------------------------------------------------
> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/4/_/830676/_/959696797/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com


________________________________________________________________________
________________________________________________________________________

Message: 17
Date: Tue, 30 May 2000 09:29:35 -0600
From: Tim Uckun <tim@...>
Subject: Re: Fw: Mischievous SYSDBA


>
>Is the application restricted to the native InterBase API? Or must
>the solution work with ODBC, JDBC, BDE, etc? Does there need to
>be an escape for third party report writers, etc? Do you need
>to be able to back it up?

Of course the data needs to be backed up. I don't see that as a problem now
because in an embedded application this is simply just backing up the data
files. If we get incremental backups that would be different. I don't think
the communication mechanism should matter so much. Presuming some sort of a
challenge/response or a key/ticket exchange it should not rely on the
transport mechanism.


>What threats should the mechanism reasonable protect against? A
>well meaning but misadvised user? An application program wanting
>to write an extension? A competing developer?

all of the above (as long as I am wishing). Seriously though.. Mostly from
casual snoopers. Most developers of database applications tend to use high
end programming tools like VB, Delphi or do web based stuff using PHP,
JAVA, ASP, Cold Fusion etc. I just don't see these people expending so much
effort trying to break some security mechanism. I also don't see some
vertical market or a custom written application getting the attention
of hackers. Hackers usually want to crack commercial general use programs.
:wq
Tim Uckun
Due Diligence Inc. http://www.diligence.com/ Americas Background
Investigation Expert.
If your company isn't doing background checks, maybe you haven't considered
the risks of a bad hire.



________________________________________________________________________
________________________________________________________________________

Message: 18
Date: Tue, 30 May 2000 09:33:35 -0600
From: Tim Uckun <tim@...>
Subject: RE: Fw: Mischievous SYSDBA

At 10:46 AM 05/30/2000 -0400, you wrote:
>Tim,
>
>And what about legitimate access via third party software??? [Excel via
>ODBC, Crystal Reports via OLE DB, Cognos PowerPlay 7.0 by native
>connection (we can hope)].

If you need to have access to it using ODBC you can always leave the
encryption off. If the ODBC driver was written with the encryption as an
option in the DSN it could decode the data for you.
:wq
Tim Uckun
Due Diligence Inc. http://www.diligence.com/ Americas Background
Investigation Expert.
If your company isn't doing background checks, maybe you haven't considered
the risks of a bad hire.



________________________________________________________________________
________________________________________________________________________

Message: 19
Date: Tue, 30 May 2000 11:42:46 -0400
From: Dalton Calford <dcalford@...>
Subject: Re: Fw: Mischievous SYSDBA

This is a interesting problem.

Perhaps, this is also a way to put a minor level of security onto the
database without alot of work.

If the connect/create api, included the passing of a key value (128 bit
or maybe as long as the page size - size to be figured out once all
things are considered) AND all transmissions/storage in the database
used the key as a basic XOR on operations/data, we would have a very
basic encryption by obscurity mechinism in place that would cover over
the wire data transmission as well.

Only those applications that have the key encoded in them could connect
to the database, even if they had a proper users name and password.

Anyone trying to look at the data via a binary editor would need to have
the key and know where the data starts and stops within the structure
(ie, a smallint would only use the first two bytes of the key, while a
char(16) would use a full 16 bytes of a 128 bit key)

The only real method of decrypting such a system would be to try a brute
force attack on the database or guess the key.

Since the system is only performing a simple XOR operation, no complex
encryption/decryption routines need be implemented in the server, only a
encode/decode layer which prepares the data.

This is far from perfect, but may cover all the points asked for by
people on the list.

best regards

Dalton


Jim Starkey wrote:
>
> At 08:37 AM 5/30/00 -0600, Tim Uckun wrote:
> >
> >There ought to exists a mechanism such that only the application I have
> >written should have any access to the data and schema.
> >
> >
> >That's it. The file ought to be utterly useless to anything and anybody
> >other then my application. My application will interact with the data and
> >show the results to my customer if, where, when and how I want.
>
> Is the application restricted to the native InterBase API? Or must
> the solution work with ODBC, JDBC, BDE, etc? Does there need to
> be an escape for third party report writers, etc? Do you need
> to be able to back it up?
>
> What threats should the mechanism reasonable protect against? A
> well meaning but misadvised user? An application program wanting
> to write an extension? A competing developer?
>
> Jim Starkey
>
> ------------------------------------------------------------------------
> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/4/_/830676/_/959697861/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com


________________________________________________________________________
________________________________________________________________________

Message: 20
Date: Tue, 30 May 2000 08:45:00 -0700
From: "Markus Kemper" <mkemper@...>
Subject: Re: SuperServer vs. Classic


> This is the single most difficult and important question facing future
> development. Among the issues:
>
> 1. SuperServer only works on threaded platforms.
>
> Which platforms would this eliminate?

I (think) SCO OpenServer would be the only v5.x port
that would fall victim here. A gentleman as SCO
suggested investigation into GNU Pthreads or FSU
Pthreads as something to investigate for thread
support on OS5. Or perhaps moving to UNIXWare?

Markus


________________________________________________________________________
________________________________________________________________________

Message: 21
Date: Tue, 30 May 2000 12:08:50 -0400
From: "Leyne, Sean" <InterbaseArchitecture@...>
Subject: RE: SuperServer vs. Classic


Referring to you posting on the general listserver, this platform
represents only 0.8% of the current IB install base.

Accordingly, I think this platform can be "sacrificed to the gods".


Sean
-----Original Message-----
From: Markus Kemper [mailto:mkemper@...]
Sent: Tuesday, May 30, 2000 11:45 AM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] SuperServer vs. Classic


> This is the single most difficult and important question facing
future
> development. Among the issues:
>
> 1. SuperServer only works on threaded platforms.
>
> Which platforms would this eliminate?

I (think) SCO OpenServer would be the only v5.x port
that would fall victim here. A gentleman as SCO
suggested investigation into GNU Pthreads or FSU
Pthreads as something to investigate for thread
support on OS5. Or perhaps moving to UNIXWare?

Markus

------------------------------------------------------------------------
Missing old school friends? Find them here:
http://click.egroups.com/1/4055/4/_/830676/_/959702073/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com




________________________________________________________________________
________________________________________________________________________

Message: 22
Date: Tue, 30 May 2000 12:21:52 -0400
From: "Leyne, Sean" <InterbaseArchitecture@...>
Subject: RE: SuperServer vs. Classic

Dalton,

I don't agree.

Support for thread management across servers ("beowolf type constructs")
should NOT have any impact on the dropping Classic decision.

Let's get IB running on server equipment and solving problems which
exist in 90+% of the existing environments. The "beowolf" situation you
describe falls well outside of this range, I would expect applies to
less than 0.5% of cases (something like support for SCO).

Finally, IB can't (and shouldn't) be all things to all
people/users/developers. I have detected a tone running through a
number of the postings lately which have tended to suggest otherwise.


Sean
-----Original Message-----
From: Dalton Calford [mailto:dcalford@...]
Sent: Tuesday, May 30, 2000 11:31 AM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] SuperServer vs. Classic

I personally would not want to see the classic version dropped until
supersever supports threads that work across processors (and by
extension accross machines in beowolf type constructs).

best regards

Dalton

Jim Starkey wrote:
>
> At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:
> >
> >All this applies to superserver, of course. Classic should just be
taken
> >into the woods and shot.
> >
>
> This is the single most difficult and important question facing future
> development. Among the issues:
>
> 1. SuperServer only works on threaded platforms.
> 2. Security is hopeless in Classic
> 3. The conditionalization of the code makes ongoing maintenance
> of two branches highly problematic.
> 4. Support both on the same machine borders on impossible
> 5. Given an abstract workload, neither is a clear winner.
> Given a specific workload, one will generally outshine
> the other.
> 6. Asking the using at installation time which to install
> time is problematic -- how could a new use possible make
> an intelligent decision.
>
> An argument can me made -- but I haven't convinced Charlie -- that
> removing Classic will speed up SuperServer (algorithms are now chosen
> that work well in both), and that speeding up SuperService is
necessary
> to kill off Classic. Chicken, egg.
>
> Thoughts?
>
> Jim Starkey
>
>
------------------------------------------------------------------------
> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/4/_/830676/_/959696797/
>
------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com

------------------------------------------------------------------------
Best friends, most artistic, class clown Find 'em here:
http://click.egroups.com/1/4054/4/_/830676/_/959700578/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com




________________________________________________________________________
________________________________________________________________________

Message: 23
Date: Tue, 30 May 2000 12:21:58 -0400
From: Jim Starkey <jas@...>
Subject: New API -- Request for Comments

Below is a sample program and formal specification of the C++
Jdbc interface that I'm developing as part of the Odbc implementation.
The sample program should be more or less self-explanatory; if not,
please don't hesitate to request a clarification.

Things that I expect to change before opening the code include:

1. Dumping openDatabase and createData calls with explicit
user and password in favor of the parameter block forms.

2. Taking the the esoterica from my other project (genHtml, etc).

3. Adding an abstract class definition for DateTime, TimeStamp,
Time and Parameters.

4. Adding or substracting to cover up sins of omission and comission.

The Blob and Clob classes diverge slightly from the Jdbc specification
on the getBytes and getSubString methods. There are two problems.
First, in Java, a programmer can get the size of a returned array.
Second, in Windows at least, memory allocated in a DLL cannot be
safely released from the main program or another DLL, so releasing
a byte or character vector is problematic. ResultSet handles the
problem by caching the string until the next "next" or "release"
call, but I'm uncomfortable about doing this for large blobs. Hence
the caller is responsible for memory allocation. I've also added
Blob::getSegmentLength and Blob::getSegment calls to support the
following sort of loop to avoid the need for explicit memory
allocation:

for (int l, offset = 0; l = blob->getSegmentLength(offset); offset += l)
printf ("%*s", length, blob->getSegment (offset));

I have temporarily ducked the question of unicode. I think the best
solution would to double up all setString and getString calls with
getUnicodeString and setUnicodeString. There is a trend towards
obscuring the different between Ascii and Unicode with conditional
declarations, making most source bi-modal, that I am not comfortable
with.

I have also added a StatementMetaData class to support Odbc with
functionality not in Jdbc. Necessary, but not I biggie.

I haven't (yet) defined an analog for the Jdbc DriverManager. Connections,
for the time being, are created by calling "createConnection" against
a known (or loaded) library to get an initial connection object. If
(or when) I add a driver manager, it will almost certainly use this
mechanism.

Object lifetimes are a little muddled. The Connection object uses
the method close() a la Jdbc. Statement and ResultSet have retained
close() but also have more civilized addRef() and release(); close()
indeed makes the sucker go away, so the two mechanism are sort of
complementary. Maybe we should flush close(). The metadata objects
(DatabaseMetaData, ResultSetMetaData, and StatementMetaData) live
and die with their parent objects. Blobs and Close have only the
addRef and release() mechanisms.

The DatabaseMetaDataClass, straight out of Jdbc, is an interesting
catalog of almost everything wrong with the SQL standard.

Like Jdbc, there is not explicit support for multiple transactions
per process. To get them, multiple attachments are required. There
is a temptation to add a clone() method to Connection simplify the
coding and allow sharing is the InterBase database attachment.

Note: Short is a 16 bit integer, Int is a 32 bit integer, and Long
is a 64 bit integer. Float is the standard utterly useful floating
point that the computer science types haven't been able to beat out
of retread fortran programmers. In the interest of humanity and
numerical calculation, maybe we should just say no.

In the long term, I would like to see this API evolve into the
preferred InterBase API, so please take a close look. Speak
now or forever lose your whining rights.

*********************************************************************

#include <stdio.h>
#include <Connection.h>
#include <Blob.h>
#include <SQLException.h>

main (int argc, char **argv)
{
try
{
Connection *connection = createConnection();

Parameters parameters;
parameters.putValue ("user", "jas");
parameters.putValue ("password", "in-your-dreams");
connection->openDatabase ("d:\\OdbcJdbc\\IscDbc\\employee.gdb",
&parameters);

PreparedStatement *statement = connection->prepareStatement (
"select first_name, last_name, emp_no from employee where
first_name = ?");
statement->setString (1, "Robert");

ResultSet *resultSet = statement->executeQuery();

while (resultSet->next())
{
const char *firstName = resultSet->getString ("first_name");
const char *lastName = resultSet->getString (2); // last name
short empNo = resultSet->getShort (3); // emp-no
printf ("%.10s %s.15s %d\n", firstName, lastName, empNo);
}

resultSet->release();
statement->release();
connection->close();
}
catch (SQLException *exception)
{
printf ("Query failed: %s\n", exception->getText());
delete exception;
return 1;
}

return 0;
}


*********************************************************************

class Statement;
class PreparedStatement;
class ResultSet;
class ResultList;
class DatabaseMetaData;
class ResultSetMetaData;
class Parameters;
class Blob;
class Clob;
class Parameter;
class DateTime;
class TimeStamp;
class Time;

class Connection
{
public:
virtual void openDatabase (const char *database,
const char *account,
const char *password);
virtual void createDatabase (const char *host,
const char *dbName,
const char *fileName,
const char *account,
const char *password);
virtual Parameters* createParameters();
virtual bool isConnected() = 0;
virtual void close() = 0;

virtual void prepareTransaction() = 0;
virtual void rollback() = 0;
virtual void commit() = 0;

virtual const char* genHTML (Parameters *context, long genHeaders) = 0;
virtual void freeHTML (const char *html) = 0;

virtual Statement* createStatement() = 0;
virtual PreparedStatement* prepareStatement (const char *sqlString) = 0;
virtual DatabaseMetaData* getMetaData() = 0;
virtual void ping() = 0;
virtual int hasRole (const char *schemaName, const char
*roleName) = 0;
virtual void openDatabase (const char *database, Parameters
*context) = 0;
virtual void createDatabase (const char *host, const char
*dbName, Parameters *context) = 0;
};

class Parameters
{
public:
const char * findValue (const char *name, const char
*defaultValue);
virtual void putValue (const char *name, const char *value);
virtual void putValue (const char *name, int nameLength, const
char *value, int valueLength);
virtual ~Parameters();
Parameters();

Parameter *parameters;
int count;
};



class Statement
{
public:
virtual bool execute (const char *sqlString) = 0;
virtual ResultSet* executeQuery (const char *sqlString) = 0;
virtual int getUpdateCount() = 0;
virtual bool getMoreResults() = 0;
virtual void setCursorName (const char *name) = 0;
virtual ResultSet* getResultSet() = 0;
virtual ResultList* search (const char *searchString) = 0;
virtual int executeUpdate (const char *sqlString) = 0;
virtual void close() = 0;
virtual void release() = 0;
virtual void addRef() = 0;
};

class StatementMetaData // Not from Jdbc
{
public:
virtual int getParameterCount() = 0;
virtual int getParameterType (int index) = 0;
virtual int getPrecision(int index) = 0;
virtual int getScale(int index) = 0;
virtual bool isNullable (int index) = 0;
};


class PreparedStatement : public Statement
{
public:
virtual bool execute() = 0;
virtual ResultSet* executeQuery() = 0;
virtual int executeUpdate() = 0;
virtual void setString(int index, const char * string) = 0;
virtual void setByte (int index, char value) = 0;
virtual void setShort (int index, short value) = 0;
virtual void setInt (int index, long value) = 0;
virtual void setLong (int index, QUAD value) = 0;
virtual void setBytes (int index, int length, const void *bytes)
= 0;
virtual void setFloat (int index, float value) = 0;
virtual void setDouble (int index, double value) = 0;
virtual void setNull (int index, int type) = 0;
virtual void setDate (int index, DateTime value) = 0;
virtual void setTime (int index, Time value) = 0;
virtual void setTimestamp (int index, TimeStamp value) = 0;
virtual void setBlob (int index, Blob *value) = 0;
virtual void setClob (int index, Clob *value) = 0;
virtual StatementMetaData*
getStatementMetaData() = 0;
};

class ResultSet
{
public:
virtual const char* getString (int id) = 0;
virtual const char* getString (const char *columnName) = 0;
virtual char getByte (int id) = 0;
virtual char getByte (const char *columnName) = 0;
virtual short getShort (int id) = 0;
virtual short getShort (const char *columnName) = 0;
virtual long getInt (int id) = 0;
virtual long getInt (const char *columnName) = 0;
virtual QUAD getLong (int id) = 0;
virtual QUAD getLong (const char *columnName) = 0;
virtual float getFloat (int id) = 0;
virtual float getFloat (const char *columnName) = 0;
virtual double getDouble (int id) = 0;
virtual double getDouble (const char *columnName) = 0;
virtual DateTime getDate (int id) = 0;
virtual DateTime getDate (const char *columnName) = 0;
virtual Time getTime (int id) = 0;
virtual Time getTime (const char *columnName) = 0;
virtual TimeStamp getTimestamp (int id) = 0;
virtual TimeStamp getTimestamp (const char *columnName) = 0;
virtual Blob* getBlob (int index) = 0;
virtual Blob* getBlob (const char *columnName) = 0;
virtual int findColumn (const char *columName) = 0;
virtual ResultSetMetaData* getMetaData() = 0;

virtual const char* genHTML(const char *series, const char *type,
Parameters *context) = 0;
virtual void freeHTML(const char *html) = 0;


virtual void close() = 0;
virtual bool next() = 0;
virtual void release() = 0;
virtual void addRef() = 0;
virtual bool wasNull() = 0;
};

class ResultSetMetaData
{
public:
virtual const char* getTableName (int index) = 0;
virtual const char* getColumnName (int index) = 0;
virtual int getColumnDisplaySize (int index) = 0;
virtual int getColumnType (int index) = 0;
virtual int getColumnCount() = 0;
virtual int getPrecision(int index) = 0;
virtual int getScale(int index) = 0;
virtual bool isNullable (int index) = 0;
};

class ResultList
{
public:
virtual const char* getTableName() = 0;
virtual double getScore() = 0;
virtual int getCount() = 0;
virtual ResultSet* fetchRecord() = 0;
virtual bool next() = 0;
virtual void close() = 0;
};


extern Connection* createConnection();


class Blob
{
public:
virtual void addRef() = 0;
virtual void release() = 0;
virtual void getBytes (long pos, long length, void *buffer) = 0;
virtual int length() = 0;
virtual int getSegmentLength (int pos) = 0;
virtual void *getSegment (int pos) = 0;
};

class Clob
{
public:
virtual void addRef() = 0;
virtual void release() = 0;
virtual void getSubString (long pos, long length, char *buffer) = 0;
virtual int length() = 0;
virtual int getSegmentLength (int pos) = 0;
virtual const char *getSegment (int pos) = 0;
};

class DatabaseMetaData
{
public:
virtual ResultSet* getIndexInfo (const char * catalog, const char *
schemaPattern, const char * tableNamePattern, bool unique, bool
approximate) = 0;
virtual ResultSet* getImportedKeys (const char * catalog, const char *
schemaPattern, const char * tableNamePattern) = 0;
virtual ResultSet* getPrimaryKeys (const char * catalog, const char *
schemaPattern, const char * tableNamePattern) = 0;
virtual ResultSet* getColumns (const char *catalog, const char *schema,
const char *table, const char *fieldNamePattern) = 0;
virtual ResultSet* getTables (const char *catalog, const char
*schemaPattern, const char *tableNamePattern, int typeCount, const char
**types) = 0;
virtual ResultSet* getObjectPrivileges (const char *catalog, const char
*schemaPattern, const char *namePattern, int objectType) = 0;
virtual ResultSet* getUserRoles (const char *user) = 0;
virtual ResultSet* getRoles (const char * catalog, const char * schema,
const char *rolePattern) = 0;
virtual ResultSet* getUsers (const char * catalog, const char
*userPattern) = 0;
virtual bool allProceduresAreCallable() = 0;
virtual bool allTablesAreSelectable() = 0;
virtual const char* getURL() = 0;
virtual const char* getUserName() = 0;
virtual bool isReadOnly() = 0;
virtual bool nullsAreSortedHigh() = 0;
virtual bool nullsAreSortedLow() = 0;
virtual bool nullsAreSortedAtStart() = 0;
virtual bool nullsAreSortedAtEnd() = 0;
virtual const char* getDatabaseProductName() = 0;
virtual const char* getDatabaseProductVersion() = 0;
virtual const char* getDriverName() = 0;
virtual const char* getDriverVersion() = 0;
virtual int getDriverMajorVersion() = 0;
virtual int getDriverMinorVersion() = 0;
virtual bool usesLocalFiles() = 0;
virtual bool usesLocalFilePerTable() = 0;
virtual bool supportsMixedCaseIdentifiers() = 0;
virtual bool storesUpperCaseIdentifiers() = 0;
virtual bool storesLowerCaseIdentifiers() = 0;
virtual bool storesMixedCaseIdentifiers() = 0;
virtual bool supportsMixedCaseQuotedIdentifiers() = 0;
virtual bool storesUpperCaseQuotedIdentifiers() = 0;
virtual bool storesLowerCaseQuotedIdentifiers() = 0;
virtual bool storesMixedCaseQuotedIdentifiers() = 0;
virtual const char* getIdentifierQuoteString() = 0;
virtual const char* getSQLKeywords() = 0;
virtual const char* getNumericFunctions() = 0;
virtual const char* getStringFunctions() = 0;
virtual const char* getSystemFunctions() = 0;
virtual const char* getTimeDateFunctions() = 0;
virtual const char* getSearchStringEscape() = 0;
virtual const char* getExtraNameCharacters() = 0;
virtual bool supportsAlterTableWithAddColumn() = 0;
virtual bool supportsAlterTableWithDropColumn() = 0;
virtual bool supportsColumnAliasing() = 0;
virtual bool nullPlusNonNullIsNull() = 0;
virtual bool supportsConvert() = 0;
virtual bool supportsConvert(int fromType, int toType) = 0;
virtual bool supportsTableCorrelationNames() = 0;
virtual bool supportsDifferentTableCorrelationNames() = 0;
virtual bool supportsExpressionsInOrderBy() = 0;
virtual bool supportsOrderByUnrelated() = 0;
virtual bool supportsGroupBy() = 0;
virtual bool supportsGroupByUnrelated() = 0;
virtual bool supportsGroupByBeyondSelect() = 0;
virtual bool supportsLikeEscapeClause() = 0;
virtual bool supportsMultipleResultSets() = 0;
virtual bool supportsMultipleTransactions() = 0;
virtual bool supportsNonNullableColumns() = 0;
virtual bool supportsMinimumSQLGrammar() = 0;
virtual bool supportsCoreSQLGrammar() = 0;
virtual bool supportsExtendedSQLGrammar() = 0;
virtual bool supportsANSI92EntryLevelSQL() = 0;
virtual bool supportsANSI92IntermediateSQL() = 0;
virtual bool supportsANSI92FullSQL() = 0;
virtual bool supportsIntegrityEnhancementFacility() = 0;
virtual bool supportsOuterJoins() = 0;
virtual bool supportsFullOuterJoins() = 0;
virtual bool supportsLimitedOuterJoins() = 0;
virtual const char* getSchemaTerm() = 0;
virtual const char* getProcedureTerm() = 0;
virtual const char* getCatalogTerm() = 0;
virtual bool isCatalogAtStart() = 0;
virtual const char* getCatalogSeparator() = 0;
virtual bool supportsSchemasInDataManipulation() = 0;
virtual bool supportsSchemasInProcedureCalls() = 0;
virtual bool supportsSchemasInTableDefinitions() = 0;
virtual bool supportsSchemasInIndexDefinitions() = 0;
virtual bool supportsSchemasInPrivilegeDefinitions() = 0;
virtual bool supportsCatalogsInDataManipulation() = 0;
virtual bool supportsCatalogsInProcedureCalls() = 0;
virtual bool supportsCatalogsInTableDefinitions() = 0;
virtual bool supportsCatalogsInIndexDefinitions() = 0;
virtual bool supportsCatalogsInPrivilegeDefinitions() = 0;
virtual bool supportsPositionedDelete() = 0;
virtual bool supportsPositionedUpdate() = 0;
virtual bool supportsSelectForUpdate() = 0;
virtual bool supportsStoredProcedures() = 0;
virtual bool supportsSubqueriesInComparisons() = 0;
virtual bool supportsSubqueriesInExists() = 0;
virtual bool supportsSubqueriesInIns() = 0;
virtual bool supportsSubqueriesInQuantifieds() = 0;
virtual bool supportsCorrelatedSubqueries() = 0;
virtual bool supportsUnion() = 0;
virtual bool supportsUnionAll() = 0;
virtual bool supportsOpenCursorsAcrossCommit() = 0;
virtual bool supportsOpenCursorsAcrossRollback() = 0;
virtual bool supportsOpenStatementsAcrossCommit() = 0;
virtual bool supportsOpenStatementsAcrossRollback() = 0;
virtual int getMaxCharLiteralLength() = 0;
virtual int getMaxColumnNameLength() = 0;
virtual int getMaxColumnsInGroupBy() = 0;
virtual int getMaxColumnsInIndex() = 0;
virtual int getMaxColumnsInOrderBy() = 0;
virtual int getMaxColumnsInSelect() = 0;
virtual int getMaxColumnsInTable() = 0;
virtual int getMaxConnections() = 0;
virtual int getMaxCursorNameLength() = 0;
virtual int getMaxIndexLength() = 0;
virtual int getMaxSchemaNameLength() = 0;
virtual int getMaxProcedureNameLength() = 0;
virtual int getMaxCatalogNameLength() = 0;
virtual int getMaxRowSize() = 0;
virtual bool doesMaxRowSizeIncludeBlobs() = 0;
virtual int getMaxStatementLength() = 0;
virtual int getMaxStatements() = 0;
virtual int getMaxTableNameLength() = 0;
virtual int getMaxTablesInSelect() = 0;
virtual int getMaxUserNameLength() = 0;
virtual int getDefaultTransactionIsolation() = 0;
virtual bool supportsTransactions() = 0;
virtual bool supportsTransactionIsolationLevel(int level) = 0;
virtual bool supportsDataDefinitionAndDataManipulationTransactions() =
0;
virtual bool supportsDataManipulationTransactionsOnly() = 0;
virtual bool dataDefinitionCausesTransactionCommit() = 0;
virtual bool dataDefinitionIgnoredInTransactions() = 0;
virtual ResultSet* getProcedures(const char* catalog, const char*
schemaPattern,
const char* procedureNamePattern) = 0;

virtual ResultSet* getProcedureColumns(const char* catalog,
const char* schemaPattern,
const char* procedureNamePattern,
const char* columnNamePattern) = 0;

virtual ResultSet* getSchemas() = 0;
virtual ResultSet* getCatalogs() = 0;
virtual ResultSet* getTableTypes() = 0;
virtual ResultSet* getColumnPrivileges(const char* catalog, const char*
schema,
const char* table, const char* columnNamePattern) = 0;

virtual ResultSet* getTablePrivileges(const char* catalog, const char*
schemaPattern,
const char* tableNamePattern) = 0;

virtual ResultSet* getBestRowIdentifier(const char* catalog, const
char* schema,
const char* table, int scope, bool nullable) = 0;

virtual ResultSet* getVersionColumns(const char* catalog, const char*
schema,
const char* table) = 0;

virtual ResultSet* getExportedKeys(const char* catalog, const char*
schema,
const char* table) = 0;

virtual ResultSet* getCrossReference(
const char* primaryCatalog, const char* primarySchema, const char*
primaryTable,
const char* foreignCatalog, const char* foreignSchema, const char*
foreignTable
) = 0;

virtual ResultSet* getTypeInfo() = 0;
virtual bool supportsResultSetConcurrency(int type, int concurrency) =
0;
virtual bool ownUpdatesAreVisible(int type) = 0;
virtual bool ownDeletesAreVisible(int type) = 0;
virtual bool ownInsertsAreVisible(int type) = 0;
virtual bool othersUpdatesAreVisible(int type) = 0;
virtual bool othersDeletesAreVisible(int type) = 0;
virtual bool othersInsertsAreVisible(int type) = 0;
virtual bool updatesAreDetected(int type) = 0;
virtual bool deletesAreDetected(int type) = 0;
virtual bool insertsAreDetected(int type) = 0;
virtual bool supportsBatchUpdates() = 0;
virtual ResultSet* getUDTs(const char* catalog, const char*
schemaPattern,
const char* typeNamePattern, int* types) = 0;
};


Jim Starkey


________________________________________________________________________
________________________________________________________________________

Message: 24
Date: Tue, 30 May 2000 12:35:21 -0400
From: Jim Starkey <jas@...>
Subject: Re: Fw: Mischievous SYSDBA

At 09:29 AM 5/30/00 -0600, Tim Uckun wrote:
>
>
>Of course the data needs to be backed up. I don't see that as a problem now

>because in an embedded application this is simply just backing up the data
>files. If we get incremental backups that would be different. I don't think

>the communication mechanism should matter so much. Presuming some sort of a

>challenge/response or a key/ticket exchange it should not rely on the
>transport mechanism.
>

Problem: gbak will need the key (or whatever) to access the restriction
portion of the database. Unless we can come up with something tricky,
this means giving the key to the system administrator, who is the one
we're trying to protect the data from.

>
>>What threats should the mechanism reasonable protect against? A
>>well meaning but misadvised user? An application program wanting
>>to write an extension? A competing developer?
>
>all of the above (as long as I am wishing). Seriously though.. Mostly from
>casual snoopers. Most developers of database applications tend to use high
>end programming tools like VB, Delphi or do web based stuff using PHP,
>JAVA, ASP, Cold Fusion etc. I just don't see these people expending so much

>effort trying to break some security mechanism. I al<br/><br/>(Message over 64 KB, truncated)