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 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.

Does this mean that the protection mechanism must work through
sanctioned program using these interfaces? Defining something
that is accessible through ODBC is quite a different beast than
something limited to the native API.

Jim Starkey