Jim,

> In addition, a security manager could reasonably expected to get

involved

> in
>
> 1. File open, so a database could be kept on a password protected

or

> encrypted volume
> 2. Physical read and writes, so physical data can be encrypted at

the

> page level
> 3. TCP connections, to enable use of SSL between the client and

server

Personally, I think that this is too broad a definition. These are
separate problems.

Database encryption has little to do with the user authentication
method, the same is true for the method by which the server/client
choose to communicate.

The scope of the problem should be broken up into the separate elements,
which you've outlined, each with its own API definition.

The fact that all share some aspect of "security" doesn't mean that they
need to be "hit with a single hammer".

> The Vulcan configuration file systems makes it easy to design the
> mechanism for specification of and parameters for security managers on

a

> per-database basis, so all sorts of specialized schemes are possible

and

> probably even desirable.

I read to mean that it will be necessary for the SYSDBA to define a
configuration file for each database on the server, correct?

Isn't it more appropriate to think of the user and encryption security
settings as something which is stored within the database (in the header
page, so that the settings are "hard-wired" for the database?

The question of the SSL or client/server transport security would be a
setting of the server, why would it vary by database? I can't think of
any network admin allowing for mixed communication modes over a network
interface.


Sean