At 01:33 PM 5/5/01 -0400, Brad Clements wrote:

>We use Firebird/Interbase with Zope on several systems. Unfortunately Zope

logs in

>with one connection and so its hard to equate a web-login to an SQL request.
>
>What would be interesting is being able to specify a userid PER TRANSACTION,
>
>so when I call begin(), I can pass in the userid to use..
>
>Maybe this is the place to do it, not in a table trigger. This would

require changes in the

>client and protocol, but I think would be more generally useful because it

would apply to

>any transaction, not just to a table.
>

Virtually every web application has a server process running under one
database login acting on behalf of a client. Traditional database
security recognizes only the database login account, leaving client
specific security checking strictly the reasonsibility of the application
program. In the past, this made sense. Now, it doesn't.

It is clear to me that current usage for database systems suggests
the that database system enforce two level security, which means
the application must have some means to indicate when it is operating
as the application and when it is operation on behalf of a specified
client. Whether or not clients are actually known by the dbms is
a separate and interesting question.

The reason to do this is twofold. First, security policy is better
centralizedin the database than implemented in application code.
Second, any selection performed to implement security policy
(row level security) is be done before request optimization.

I don't think associating a client with a transaction is the right
answer since it is possible, even likely, that the security scope
change change within a transaction or span several transactions.

What I do think makes sense is a) a more flexible role model
that supports dynamic activation/deactivation of roles, and
b) a mechanism for settable connection attributes accessible
by triggers and stored procedures.


Jim Starkey